Eingeschränkten Zugriff für private GKE-Cluster konfigurieren

Durch die Konfiguration des DNS-Routings zu einer eingeschränkten virtuellen IP-Adresse (VIP) können private Google Kubernetes Engine-Cluster auf Artifact Registry-Repositories innerhalb eines VPC Service Controls-Dienstperimeters zugreifen.

Da private Clusterknoten vom Internet isoliert sind und Registry-Domains standardmäßig in öffentliche IP-Adressen aufgelöst werden, müssen Sie Anfragen für die Domains pkg.dev und gcr.io über die eingeschränkte VIP weiterleiten.

Übersicht

Ihre privaten Cluster sollten immer mit der eingeschränkten VIP auf Artifact Registry oder Container Registry zugreifen, um die Daten-Exfiltration von einem unterstützten Dienst zu einem nicht unterstützten Dienst zu verhindern.

Konfigurieren Sie den eingeschränkten Zugriff für private GKE-Cluster, wenn alle folgenden Bedingungen erfüllt sind:

  • Sie verwenden private GKE-Cluster.
  • Sie haben das Routing der Registry-Domains pkg.dev oder gcr.io zu restricted.googleapis.com noch nicht konfiguriert.

Hinweis

Bevor Sie einen Dienstperimeter erstellen, müssen Sie einen neuen privaten Cluster einrichten oder die vorhandenen privaten Cluster benennen, die Sie schützen möchten.

Außerdem müssen Sie ausgehenden Traffic an 199.36.153.4/30 auf Port 443 zulassen. Normalerweise hat ein VPC-Netzwerk eine implizierte Regel, die den gesamten ausgehenden Traffic an ein beliebiges Ziel zulässt. Wenn Sie jedoch eine Regel haben, die einen solchen Traffic ablehnt, müssen Sie eine Firewallregel für ausgehenden Traffic erstellen, um den TCP-Traffic auf Port 443 an 199.36.153.4/30 zuzulassen.

DNS konfigurieren

Konfigurieren Sie Ihren DNS-Server so, dass Anfragen an Registry-Adressen in restricted.googleapis.com, die eingeschränkte VIP, aufgelöst werden. Dazu können Sie private DNS-Zonen von Cloud DNS verwenden.

  1. Erstellen Sie eine verwaltete private Zone.

    gcloud dns managed-zones create ZONE_NAME \
    --visibility=private \
    --networks=https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK \
    --description=DESCRIPTION \
    --dns-name=REGISTRY_DOMAIN \
    --project=PROJECT_ID

    Wobei:

    • ZONE_NAME ist ein Name für die Zone, die Sie erstellen. Beispiel: registry. Dieser Name wird in den folgenden Schritten verwendet.
    • PROJECT_ID ist die ID des Projekts, in dem Ihr privater GKE-Cluster gehostet wird.
    • NETWORK ist eine optionale Liste von Namen des Clusternetzwerks, von dem Sie Anfragen weiterleiten möchten.
    • DESCRIPTION ist eine menschenlesbare Beschreibung der verwalteten Zone.
    • REGISTRY_DOMAIN ist die Domain für Ihre Registry:
      • pkg.dev für Artifact Registry
      • gcr.io für Container Registry oder gcr.io-Repositories, die in Artifact Registry gehostet werden

  2. Starten Sie eine Transaktion.

    gcloud dns record-sets transaction start \
  --zone=ZONE_NAME \
  --project=PROJECT_ID

    Dabei gilt:

    • ZONE_NAME ist der Name der Zone, die Sie im ersten Schritt erstellt haben.

    • PROJECT_ID ist die ID des Projekts, in dem der private GKE-Cluster gehostet wird.

  3. Fügen Sie einen CNAME-Eintrag für Ihre Registry hinzu.

    gcloud dns record-sets transaction add \
  --name=*.REGISTRY_DOMAIN. \
  --type=CNAME REGISTRY_DOMAIN. \
  --zone=ZONE_NAME \
  --ttl=300 \
  --project=PROJECT_ID

    Wobei:

    • ZONE_NAME ist der Name der Zone, die Sie im ersten Schritt erstellt haben.
    • PROJECT_ID ist die ID des Projekts, in dem Ihr privater GKE-Cluster gehostet wird.
    • REGISTRY_DOMAIN ist die Domain für Ihre Registry:
      • pkg.dev für Artifact Registry
      • gcr.io für Container Registry oder gcr.io-Repositories, die in Artifact Registry gehostet werden

  4. Fügen Sie einen A-Eintrag für die eingeschränkte VIP hinzu.

    gcloud dns record-sets transaction add \
  --name=REGISTRY_DOMAIN. \
  --type=A 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 \
  --zone=ZONE_NAME \
  --ttl=300 \
  --project=PROJECT_ID

    Wobei:

    • ZONE_NAME ist der Name der Zone, die Sie im ersten Schritt erstellt haben.
    • PROJECT_ID ist die ID des Projekts, in dem Ihr privater GKE-Cluster gehostet wird.
    • REGISTRY_DOMAIN ist die Domain für Ihre Registry:
      • pkg.dev für Artifact Registry
      • gcr.io für Container Registry oder in Artifact Registry gehostete gcr.io-Repositories

  5. Führen Sie die Transaktion aus.

    gcloud dns record-sets transaction execute \
  --zone=ZONE_NAME \
  --project=PROJECT_ID

    Dabei gilt:

    • ZONE_NAME ist der Name der Zone, die Sie im ersten Schritt erstellt haben.

    • PROJECT_ID ist die ID des Projekts, in dem der private GKE-Cluster gehostet wird.

Nachdem Sie das DNS-Routing konfiguriert haben, müssen Sie dafür sorgen, dass sich GKE, die Registry und andere erforderliche Dienste innerhalb des VPC Service Controls-Dienstperimeters befinden. Informationen zum Konfigurieren des Dienstperimeters finden Sie im folgenden Abschnitt.

Dienstperimeter konfigurieren

Nachdem Sie die DNS-Einträge konfiguriert haben, gehen Sie so vor:

  1. Erstellen Sie einen neuen Dienstperimeter oder aktualisieren Sie einen vorhandenen Perimeter.
  2. Fügen Sie den Container Registry- oder Artifact Registry-Dienst zur Liste der Dienste hinzu, die durch den Dienstperimeter geschützt werden sollen.
  3. Fügen Sie dem Dienstperimeter weitere unterstützte Dienste hinzu, die Sie mit der Registry verwenden, z. B. Cloud Build, Artefaktanalyse und Binärautorisierung.
  4. Wenn Sie auf Container Registry zugreifen müssen, müssen Sie auch Cloud Storage zum Dienstperimeter hinzufügen.

Perimeterfunktion prüfen

Nachdem Sie den Dienstperimeter konfiguriert haben, können Ihre Knoten in privaten GKE-Clustern auf Container-Images in Artifact Registry und Container Registry zugreifen, wenn die Images in Projekten gespeichert sind, die sich in Ihrem Dienstperimeter befinden.

Container-Images in Projekten außerhalb des Perimeters bleiben unzugänglich, mit Ausnahme einiger bestimmter schreibgeschützter öffentlicher Repositories.

Wenn sich das Projekt google-samples beispielsweise nicht in Ihrem Dienstperimeter befindet, schlägt das Ausführen des Befehls zum Erstellen eines Deployments aus dem Container hello-app fehl:

pkg.dev -Domain 

kubectl create deployment hello-server --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

gcr.io-Domain 

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

Prüfen Sie den Status des Pods mit folgendem Befehl:

kubectl get pods

Der Befehl gibt eine Tabelle in etwa wie in folgendem Beispiel zurück. Der Pod-Status ErrImagePull gibt an, dass der Pull-Vorgang fehlgeschlagen ist.

NAME                            READY   STATUS         RESTARTS   AGE
hello-server-dbd86c8c4-h5wsf    1/1     ErrImagePull   0          45s

Mit dem Befehl kubectl describe pod können Sie weitere Details zur Bereitstellung aufrufen. Für den Pod aus dem vorherigen Beispiel lautet der Befehl:

kubectl describe pod hello-server-dbd86c8c4-h5wsf