Mit Identity Service for GKE auf private Google Kubernetes Engine-Cluster aus privaten Cloud Build-Pools zugreifen

---

In dieser Anleitung wird beschrieben, wie Sie mit privaten Cloud Build-Pools auf die Steuerungsebene eines privaten GKE-Clusters (Google Kubernetes Engine) zugreifen. Mit diesem Zugriff können Sie Cloud Build verwenden, um Anwendungen in einem privaten GKE-Cluster bereitzustellen und Ressourcen zu verwalten. Diese Anleitung richtet sich an Plattformadministratoren, Clusteradministratoren und Entwickler. Dabei wird davon ausgegangen, dass Sie mit GKE, Cloud Build, OpenID Connect und dem gcloud-Befehlszeilentool vertraut sind.

Private Cloud Build-Pools und GKE-Cluster-Steuerungsebenen werden beide in Google-VPC-Netzwerken (Virtual Private Cloud) ausgeführt. Diese VPC-Netzwerke sind über Peering mit Ihrem eigenen VPC-Netzwerk in Google Cloudverbunden. VPC-Netzwerk-Peering unterstützt jedoch kein transitives Peering. Dies kann bei der Verwendung privater Cloud Build-Pools eine Einschränkung sein. In dieser Anleitung wird eine Lösung vorgestellt, bei der Worker in einem privaten Cloud Build-Pool mithilfe des Identity Service for GKE auf die Steuerungsebene eines privaten GKE-Clusters zugreifen können.

Architektur

Identity Service for GKE ist ein Authentifizierungs-Proxy für GKE-Cluster-Steuerungsebenen. Er stellt Anfragen an den API-Server weiter und validiert ID-Tokens, die von OpenID Connect (OIDC)-Identitätsanbietern ausgestellt wurden. Nachdem der Proxy ein ID-Token erfolgreich validiert hat, fügt er der ursprünglichen Anfrage HTTP-Header zur Nutzeridentitätsdiebstahl-Vortäuschung hinzu und leitet sie an den API-Server weiter. Der Proxy wird als Kubernetes-Dienstkonto ausgeführt, das Berechtigungen zum Annehmen der Identität von Nutzern und Gruppen hat.

Der Identity Service for GKE-Proxy wird als Pod auf Clusterknoten ausgeführt. Ein Kubernetes-Dienst vom Typ LoadBalancer stellt den Proxy außerhalb des Clusters bereit. Wenn Identity Service for GKE in einem privaten Cluster aktiviert ist, fügt das Installationsprogramm dem Kubernetes-Dienst eine Annotation hinzu, um einen internen Passthrough-Network Load Balancer bereitzustellen. Auf den Proxy kann über den Load Balancer über eine VPC-Netzwerk-Peering-Verbindung zugegriffen werden, z. B. von einem Cloud Build-Private-Pool, da der Proxy auf Clusterknoten in Ihrem VPC-Netzwerk ausgeführt wird.

Sie können Google im Identity Service für GKE als OpenID Connect-Identitätsanbieter konfigurieren, da das OAuth 2.0-Authentifizierungssystem von Google der OpenID Connect-Spezifikation entspricht. Um ID-Tokens für ein Google-Dienstkonto abzurufen, können Sie die Methode generateIdToken der Service Account Credentials API verwenden. Die ID-Tokens werden von Google ausgestellt und signiert.

Zusammenfassend ermöglicht diese Lösung den Zugriff auf die Steuerungsebene des privaten GKE-Clusters über den Identity Service for GKE-Proxy. Builds, die in einem privaten Cloud Build-Pool ausgeführt werden, stellen über eine VPC-Netzwerk-Peering-Verbindung eine Verbindung zum Proxy her. Der Build, der im privaten Cloud Build-Pool ausgeführt wird, wird als Google-Dienstkonto ausgeführt. Dieses Google-Dienstkonto kann über die Service Account Credentials API ein ID-Token abrufen, um sich beim Proxy zu authentifizieren.

Das folgende Diagramm zeigt die im vorherigen Text beschriebene Architektur:

Die gesamte Kommunikation in dieser Lösung erfolgt über den internen IP‑Adressbereich. Die Worker im privaten Pool benötigen keine öffentliche Internetverbindung.

IAM-Berechtigungen (Identity and Access Management), die Nutzerkonten und Google-Dienstkonten gewährt werden, gelten nicht, wenn sie sich über den Identitätsdienst für GKE authentifizieren. Stattdessen verwenden Sie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes, um Clusterberechtigungen für diese Konten zu verwalten.

Hinweise

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
2. Install the Google Cloud CLI.

3. To initialize the gcloud CLI, run the following command:

   gcloud init

4. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

5. Make sure that billing is enabled for your Google Cloud project.

6. Enable the Cloud Build, GKE, Identity-Aware Proxy (IAP), and Service Networking APIs APIs:

   gcloud services enable cloudbuild.googleapis.com container.googleapis.com iap.googleapis.com servicenetworking.googleapis.com

7. Install the Google Cloud CLI.

8. To initialize the gcloud CLI, run the following command:

   gcloud init

9. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

10. Make sure that billing is enabled for your Google Cloud project.

11. Enable the Cloud Build, GKE, Identity-Aware Proxy (IAP), and Service Networking APIs APIs:

    gcloud services enable cloudbuild.googleapis.com container.googleapis.com iap.googleapis.com servicenetworking.googleapis.com

Privaten GKE-Cluster erstellen

1. Erstellen Sie in Cloud Shell einen GKE-Cluster ohne Clientzugriff auf den öffentlichen Endpunkt der Steuerungsebene und mit installiertem Identity Service für GKE:

   gcloud container clusters create CLUSTER  \
     --enable-identity-service \
     --enable-ip-alias \
     --enable-master-authorized-networks \
     --enable-private-endpoint \
     --enable-private-nodes \
     --master-ipv4-cidr CONTROL_PANE_CIDR \
     --network NETWORK\
     --release-channel regular \
     --scopes cloud-platform \
     --subnetwork SUBNET \
     --tags NODE_TAGS \
     --workload-pool PROJECT_ID.svc.id.goog \
     --zone ZONE
   

   Ersetzen Sie Folgendes:

   • CLUSTER ist der Name des Clusters. Verwenden Sie für diese Anleitung private-cluster.
   • CONTROL_PANE_CIDR: den IP-Adressbereich der Steuerungsebene. Sie muss das Präfix /28 haben. Für diese Anleitung können Sie 172.16.0.32/28 verwenden.
   • NETWORK: Das VPC-Netzwerk, mit dem die Steuerungsebene verbunden ist. Verwenden Sie für diese Anleitung default.
   • SUBNET: das Subnetzwerk, mit dem die GKE-Cluster-Steuerungsebene verbunden ist. Das Subnetz muss zum VPC-Netzwerk gehören, das durch NETWORK angegeben ist. Verwenden Sie für diese Anleitung default.
   • NODE_TAGS: eine durch Kommas getrennte Liste von Netzwerk-Tags, die auf die Knoten angewendet werden sollen. Verwenden Sie für diese Anleitung private-cluster-node.
   • PROJECT_ID: Ihre Google Cloud Projekt-ID.
   • ZONE: die Zone für den GKE-Cluster. Verwenden Sie für diese Anleitung us-central1-f.

   Beachten Sie für den Befehl Folgendes:

   • Mit dem Flag --enable-identity-service wird Identity Service for GKE im Cluster aktiviert. In Ihrer eigenen Umgebung können Sie Identity Service for GKE in einem vorhandenen Cluster aktivieren.

   • Mit dem Flag --enable-private-endpoint wird die Steuerungsebene so konfiguriert, dass nur über interne IP-Adressen darauf zugegriffen werden kann.

   • Mit dem Flag --enable-private-nodes werden die Clusterknoten so konfiguriert, dass sie nur interne IP-Adressen haben.

   • Mit den Flags --enable-master-authorized-networks und --enable-private-nodes ist der Zugriff auf den API-Server nur von den privaten Netzwerken möglich, die mit dem Flag --network angegeben sind.

   • Mit dem optionalen Flag --workload-pool wird die Identitätsföderation von Arbeitslasten für GKE aktiviert. Für diese Anleitung ist das nicht erforderlich.

2. Fügen Sie eine Firewallregel hinzu, mit der die Steuerungsebene des GKE-Clusters eine Verbindung zum Validierungs-Zulassungs-Webhook für ClientConfig-Ressourcen herstellen kann:

   gcloud compute firewall-rules create allow-control-plane-clientconfig-webhook \
     --allow tcp:15000 \
     --network NETWORK\
     --source-ranges CONTROL_PANE_CIDR\
     --target-tags NODE_TAGS
   

   ClientConfig ist ein benutzerdefinierter Kubernetes-Ressourcentyp (CRD), mit dem Identity Service for GKE die Interaktion mit Identitätsanbietern konfiguriert.

Identity Service für GKE als OAuth 2.0-Clientanwendung registrieren

In diesem Abschnitt registrieren Sie Identity Service for GKE als Clientanwendung mit dem OAuth 2.0-Authentifizierungssystem von Google.

1. Öffnen Sie in der Google Cloud Console die Seite Anmeldedaten.

   Öffnen Sie die Seite Anmeldedaten

2. Klicken Sie auf Anmeldedaten erstellen.

3. Wählen Sie OAuth-Client-ID aus.

   Wenn der Einwilligungsbildschirm für das Google Cloud-Projekt noch nicht konfiguriert wurde, klicken Sie auf Zustimmungsbildschirm konfigurieren. Folgen Sie der Dokumentation zum Konfigurieren des Einwilligungsbildschirms. Legen Sie für diese Anleitung die folgenden Werte fest:

   • Als Nutzertyp kann entweder Intern oder Extern ausgewählt werden. Wählen Sie für diese Anleitung „Intern“ aus.
   • Die Werte für App-Name, E-Mail-Adresse für den Nutzersupport und Kontaktdaten des Entwicklers sind erforderlich und können beliebig sein.
   • Für diese Anleitung müssen Sie keine Bereiche hinzufügen.

   Wenn Sie mit der Konfiguration des Einwilligungsbildschirms fertig sind, klicken Sie auf „Zurück zum Dashboard“ und beginnen Sie dann mit Schritt 1 des aktuellen Verfahrens von vorn.

4. Wählen Sie in der Liste Anwendungstyp die Option Webanwendung aus.

5. Geben Sie im Feld Name einen Namen für die Client-ID ein. Verwenden Sie für diese Anleitung Identity Service for GKE.

6. Klicken Sie auf Erstellen.

   Ein Dialogfeld wird angezeigt. Kopieren Sie den Wert von Ihre Client-ID. Sie benötigen ihn später in diesem Verfahren.

7. Klicken Sie auf OK, um das Dialogfeld zu schließen.

8. Erstellen Sie in Cloud Shell ein Verzeichnis mit dem Namen cloud-build-private-pools-gke-tutorial unter Ihrem Basisverzeichnis und wechseln Sie dann zu diesem Verzeichnis:

   mkdir -p ~/cloud-build-private-pools-gke-tutorial cd ~/cloud-build-private-pools-gke-tutorial

9. Erstellen Sie im neuen Verzeichnis eine YAML-Datei mit dem Namen client-config-patch.yaml mit Werten, die Sie später zum Patchen des Identitätsdienstes für die GKE-Client-Konfigurationsressource benötigen:

   cat << EOF > client-config-patch.yaml
   spec:
     authentication:
     - name: google-oidc
       oidc:
         clientID: CLIENT_ID
         cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
         extraParams: prompt=consent,access_type=offline
         issuerURI: https://accounts.google.com
         kubectlRedirectURI: http://localhost:10000/callback
         scopes: email
         userClaim: email
         userPrefix: '-'
   EOF
   

   Ersetzen Sie CLIENT_ID durch die OAuth-Client-ID aus dem vorherigen Schritt.

   Beachten Sie Folgendes zu diesem Patch:

   • ID-Tokens, die vom OAuth 2.0-Authentifizierungssystem von Google ausgestellt werden, enthalten eine eindeutige numerische Kennung in der Unteranforderung (Subjekt). Die Verwendung dieser nicht transparenten Kennung in Rollenbindungen erschwert die Identifizierung des Subjekts einer Rollenbindung. Mit diesem Patch wird der Identity Service für GKE so konfiguriert, dass er zum Identifizieren von Nutzern den E-Mail-Anspruch aus den ID-Tokens verwendet, anstatt den Standard-untergeordneten Anspruch.

   • Der E-Mail-Umfang wird hinzugefügt, damit die ausgestellten ID-Tokens die E-Mail-Anforderung enthalten.

   • Die Felder cloudConsoleRedirectURI, extraParams, kubectlRedirectURI und „scopes“ werden verwendet, wenn sich Entwickler mit Identity Service for GKE beim Cluster authentifizieren. Sie werden nicht verwendet, wenn sich Google-Dienstkonten beim Cluster authentifizieren. Das Feld „kubectlRedirectURI“ ist ein Pflichtfeld.

   • Das Feld userPrefix ist ein Präfix für Nutzer, die sich über den konfigurierten Identitätsanbieter authentifizieren. Der Wert '-' bedeutet kein Präfix.

   • Das Feld spec.authentication ist ein Array. Sie können mehrere OpenID Connect-Identitätsanbieter mit Identity Service for GKE verwenden. Sie können beispielsweise Google als Identitätsanbieter verwenden, um Google-Dienstkonten zu authentifizieren, und einen anderen Identitätsanbieter, um Entwickler zu authentifizieren.

   Weitere Informationen zu den Feldern in dieser Konfiguration finden Sie unter Externe Identitätsanbieter zur Authentifizierung bei GKE verwenden.

Google-Dienstkonto zum Konfigurieren von Identity Service for GKE erstellen

1. Erstellen Sie in Cloud Shell ein Google-Dienstkonto:

   gcloud iam service-accounts create ISG_GSA \
     --display-name "Configure Identity Service for GKE"
   

   Ersetzen Sie ISG_GSA durch den Namen, den Sie für das Google-Dienstkonto verwenden möchten. Verwenden Sie für diese Anleitung identity-service-for-gke.

   Sie weisen dieses Google-Dienstkonto einer Compute Engine-VM-Instanz zu, um Identity Service für GKE und die rollenbasierte Zugriffssteuerung von Kubernetes im Cluster zu konfigurieren.

2. Weisen Sie dem Google-Dienstkonto die Rolle Kubernetes Engine-Administrator für das Projekt zu:

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
     --role roles/container.admin
   

   Diese Rolle bietet die Berechtigungen, die für die folgenden Aufgaben in dieser Anleitung erforderlich sind:

   • Konfigurieren Sie die Einstellungen für Identity Service for GKE auf Clustern im Projekt.
   • Erstellen Sie Rollenbindungen und Clusterrollenbindungen im Cluster.

Identity Service for GKE konfigurieren

Um Identity Service for GKE zu konfigurieren, benötigen Sie Zugriff auf die Cluster-Steuerungsebene. In dieser Anleitung erstellen Sie eine Compute Engine-VM-Instanz, um auf die Kontrollebene zuzugreifen.

Sie benötigen SSH-Zugriff auf die VM-Instanz. Um authentifizierten und autorisierten SSH-Zugriff von außerhalb des VPC-Netzwerks auf die VM-Instanz zu ermöglichen, verwenden Sie die TCP-Weiterleitung mit Identity-Aware Proxy (IAP). Mit dieser Funktion ist SSH-Zugriff möglich, ohne dass die VM-Instanz eine öffentliche IP-Adresse benötigt.

1. Erstellen Sie in Cloud Shell eine Firewallregel, die den SSH-Zugriff über die IAP-TCP-Weiterleitung auf alle VM-Instanzen mit dem Netzwerk-Tag ssh-iap zulässt:

   gcloud compute firewall-rules create allow-ssh-ingress-from-iap \
     --allow tcp:22 \
     --description "Allow SSH tunneling using Identity-Aware Proxy" \
     --network NETWORK \
     --source-ranges 35.235.240.0/20 \
     --target-tags ssh-iap
   

   Der Quellbereich enthält die IP-Adressen, die IAP für die TCP-Weiterleitung verwendet.

2. Erstellen Sie eine Compute Engine-VM-Instanz im selben VPC-Netzwerk wie der GKE-Cluster:

   gcloud compute instances create VM \
     --metadata enable-oslogin=TRUE \
     --network NETWORK \
     --no-address \
     --scopes cloud-platform,userinfo-email \
     --service-account ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
     --subnet SUBNET  \
     --tags ssh-iap \
     --zone ZONE
   

   Ersetzen Sie VM durch den Namen, den Sie für die VM-Instanz verwenden möchten. Verwenden Sie für diese Anleitung identity-service-for-gke-configuration.

   Beachten Sie für den Befehl oben Folgendes:

   • Mit dem Flag --service-account wird das Google-Dienstkonto an die VM-Instanz angehängt.

   • Der Bereich cloud-platform ist erforderlich, um auf die Service Account Credentials API zuzugreifen.

   • Der Bereich userinfo-email ist hilfreich, wenn Sie eine VM-Instanz zum Verwalten der rollenbasierten Zugriffssteuerung von Kubernetes erstellen. Für diese Anleitung ist es optional.

   • Das Flag --no-address bedeutet, dass die VM-Instanz ohne externe IP-Adresse erstellt wird.

   • Mit dem optionalen Metadatenwert enable-oslogin für die Instanz wird OS Login auf der VM-Instanz aktiviert. Mit OS Login können Sie den SSH-Zugriff auf VM-Instanzen mithilfe von IAM verwalten.

3. Kopieren Sie die Patchdatei „ClientConfig“ in die VM-Instanz:

   gcloud compute scp client-config-patch.yaml VM:~ --tunnel-through-iap --zone ZONE
   

   Das Flag --tunnel-through-iap weist gcloud an, die Verbindung über IAP zu tunneln.

4. Stellen Sie eine SSH-Verbindung zur VM-Instanz her.

   gcloud compute ssh VM --tunnel-through-iap --zone ZONE
   

   Führen Sie die übrigen Befehle in diesem Abschnitt aus der SSH-Sitzung aus.

5. Installieren Sie das kubectl-Befehlszeilentool und die gke-gcloud-auth-plugin-Binärdatei in der VM-Instanz:

   sudo apt-get install -y kubectl google-cloud-sdk-gke-gcloud-auth-plugin
   

6. Rufen Sie die Anmeldedaten für den GKE-Cluster ab:

   export USE_GKE_GCLOUD_AUTH_PLUGIN=True
   gcloud container clusters get-credentials CLUSTER --zone ZONE
   

7. Patchen Sie die Standard-ClientConfig-Ressource:

   kubectl patch clientconfig default \
       --namespace kube-public \
       --patch-file client-config-patch.yaml \
       --type merge
   

8. Extrahieren Sie das Feld certificateAuthorityData aus der gepatchten Standard-ClientConfig-Ressource und speichern Sie es in einer Datei namens certificateAuthorityData.pem:

   kubectl get clientconfig default \
        --namespace kube-public \
        --output jsonpath='{.spec.certificateAuthorityData}' \
        | base64 --decode > certificateAuthorityData.pem
   

9. Extrahieren Sie das Serverfeld aus der gepatchten Standard-ClientConfig-Ressource und speichern Sie es in einer Datei namens server.txt:

   kubectl get clientconfig default \
        --namespace kube-public \
        --output jsonpath='{.spec.server}' > server.txt
   

10. Verlassen Sie die SSH-Sitzung:

    exit
    

(Optional) Clusterkonfiguration prüfen

Bevor Sie fortfahren, können Sie prüfen, ob Identity Service for GKE im Cluster korrekt eingerichtet wurde. Sie überprüfen die Einrichtung, indem Sie sich mit dem Google-Dienstkonto, das mit der VM-Instanz verknüpft ist, über den Identity Service für GKE beim Cluster authentifizieren.

1. Weisen Sie in Cloud Shell dem Dienstkonto selbst die Rolle Ersteller des OpenID Connect-Identitätstokens für das Dienstkonto zu:

   gcloud iam service-accounts add-iam-policy-binding \
     ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
     --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
     --role roles/iam.serviceAccountOpenIdTokenCreator
   

   Diese Rolle bietet die Berechtigung iam.serviceAccounts.getOpenIdToken, die zum Anfordern von ID-Tokens für das Dienstkonto über die Service Account Credentials API erforderlich ist.

2. Stellen Sie eine SSH-Verbindung zur VM-Instanz her.

   gcloud compute ssh VM --tunnel-through-iap --zone ZONE
   

   Führen Sie die übrigen Befehle in diesem Abschnitt aus der SSH-Sitzung aus.

3. Fordern Sie vom Metadatenserver ein OAuth 2.0-Zugriffstoken für das Google-Dienstkonto an, das mit der VM-Instanz verknüpft ist. Verwenden Sie dabei die OAuth-Client-ID als angeforderten aud-Anspruch (Zielgruppe):

   ACCESS_TOKEN=$(curl --silent --header "Metadata-Flavor: Google" \
   http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token \
          | python3 -c 'import json, sys; print(json.load(sys.stdin).get("access_token"))')
   

   Der Antworttext vom Metadatenserver ist ein JSON-Dokument. Der Befehl verwendet ein Inline-Python-Script, um das Feld access_token aus dem Antworttext zu extrahieren.

4. Fordern Sie ein ID-Token von der Service Account Credentials API für das Google-Dienstkonto an, das mit der VM-Instanz verknüpft ist:

   ID_TOKEN=$(curl --silent --request POST \
       --data '{"audience": "CLIENT_ID", "includeEmail": true}' \
       --header "Authorization: Bearer $ACCESS_TOKEN" \
       --header "Content-Type: application/json; charset=utf-8" \
   "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/ISG_GSA@PROJECT_ID.iam.gserviceaccount.com:generateIdToken" \
          | python3 -c 'import json, sys; print(json.load(sys.stdin).get("token"))')
   

   Beachten Sie für den Befehl oben Folgendes:

   • Das Feld audience im JSON-Anfragetext gibt den angeforderten aud-Anspruch (Zielgruppe) des ID-Tokens an.
   • Das Zugriffstoken aus dem vorherigen Schritt wird verwendet, um sich bei der API zu authentifizieren.

5. So rufen Sie die Ansprüche im ID-Token auf:

   echo $ID_TOKEN \
       | cut -d. -f2 \
       | base64 --decode --ignore-garbage 2> /dev/null \
       | python3 -m json.tool
   

   Prüfen Sie, ob der Anspruch email die E-Mail-Adresse des Google-Dienstkontos enthält.

6. Verwenden Sie das ID-Token, um sich mit Identity Service for GKE bei der Steuerungsebene zu authentifizieren:

   kubectl get namespaces \
       --certificate-authority certificateAuthorityData.pem \
       --server $(cat server.txt) \
       --token $ID_TOKEN
   

   Die Ausgabe sollte so aussehen:

     Error from server (Forbidden): namespaces is forbidden: User "ISG_GSA@PROJECT_ID.iam.gserviceaccount.com" cannot list resource "namespaces" in API group "" at the cluster scope
   

   Dieser Fehler wird erwartet. Auch wenn dem Google-Dienstkonto IAM-Berechtigungen für GKE-Cluster im Projekt gewährt wurden, gelten diese nicht, wenn Sie sich mit dem Identitätsdienst für GKE authentifizieren. Stattdessen konfigurieren Sie den Zugriff mithilfe der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes.

7. Erstellen Sie eine Clusterrollenbindung, die dem Google-Dienstkonto die Clusterrolle view zuweist, wenn sich das Dienstkonto über den OpenID Connect-Anbieter von Google beim Cluster authentifiziert:

   kubectl create clusterrolebinding ISG_GSA-cluster-view \
       --clusterrole view \
       --user ISG_GSA@PROJECT_ID.iam.gserviceaccount.com
   

   Wenn Sie in der ClientConfig in Ihrer eigenen Umgebung einen anderen userPrefix-Wert als - festlegen, fügen Sie das Präfix dem Wert des --user-Flags in diesem Befehl hinzu.

8. So greifen Sie mit Identity Service for GKE auf den GKE-Cluster zu:

   kubectl get namespaces \
       --certificate-authority certificateAuthorityData.pem \
       --server $(cat server.txt) \
       --token $ID_TOKEN
   

   Die Ausgabe sollte so aussehen:

   NAME                      STATUS   AGE
   anthos-identity-service   Active   1h
   default                   Active   1h
   kube-node-lease           Active   1h
   kube-public               Active   1h
   kube-system               Active   1h
   

9. Verlassen Sie die SSH-Sitzung:

   exit
   

Kontext für das kubectl-Tool erstellen

Der Befehl kubectl kann eine kubeconfig-Datei verwenden, um den Zugriff auf Cluster zu konfigurieren. Eine kubeconfig-Datei enthält einen oder mehrere Kontexte. Jeder Kontext hat einen Namen und enthält optional Informationen zur Clusterverbindung, Anmeldedaten für die Authentifizierung beim Cluster und einen Standard-Namespace.

In diesem Abschnitt erstellen Sie eine kubeconfig-Datei mit einem Kontext. Der Kontext enthält Verbindungsdetails des Identity Service for GKE-Proxy für Ihren Cluster. Fügen Sie der kubeconfig-Datei keine Nutzeranmeldedaten hinzu.

1. Kopieren Sie in Cloud Shell die Dateien mit den Daten der Zertifizierungsstelle und der Server-URL aus der VM-Instanz in das aktuelle Verzeichnis:

   gcloud compute scp VM:~/certificateAuthorityData.pem VM:~/server.txt . \
       --tunnel-through-iap --zone ZONE
   

2. Erstellen Sie einen Kontext und eine Clusterkonfiguration, mit denen Sie später von Cloud Build aus eine Verbindung zum GKE-Cluster herstellen:

   kubectl config set-context private-cluster \
       --cluster private-cluster \
       --kubeconfig kubeconfig
   

   Mit dem Flag --kubeconfig werden der Kontext und die Clusterkonfiguration in einer neuen Datei namens „kubeconfig“ im aktuellen Verzeichnis erstellt.

   In diesem Befehl wird der Name des GKE-Clusters als Name der Clusterkonfiguration für den Kontext verwendet. In Ihrer eigenen Umgebung können Sie im Kontext einen anderen Namen für die Clusterkonfiguration verwenden.

3. Legen Sie das Feld certificateAuthorityData in der Clusterkonfiguration fest:

   kubectl config set-cluster private-cluster \
       --certificate-authority certificateAuthorityData.pem \
       --embed-certs \
       --kubeconfig kubeconfig
   

4. Legen Sie das Feld server in der Clusterkonfiguration fest:

   kubectl config set-cluster private-cluster \
       --kubeconfig kubeconfig \
       --server $(cat server.txt)
   

Google-Dienstkonto für Cloud Build erstellen

1. Erstellen Sie in der Cloud Shell ein Google-Dienstkonto, um Builds im privaten Cloud Build-Pool auszuführen:

   gcloud iam service-accounts create CB_GSA \
     --description "Runs builds on Cloud Build private pools" \
     --display-name "Cloud Build private pool"
   

   Ersetzen Sie CB_GSA durch den Namen, den Sie für das Google-Dienstkonto verwenden möchten. Verwenden Sie für diese Anleitung cloud-build-private-pool.

2. Weisen Sie dem Google-Dienstkonto die Rolle Cloud Build-Dienstkonto für das Projekt zu:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/cloudbuild.builds.builder
   

   Diese Rolle umfasst die Standardberechtigungen des von Google verwalteten Cloud Build-Dienstkontos.

3. Weisen Sie dem Dienstkonto selbst die Rolle Ersteller des OpenID Connect-Identitätstokens für das Dienstkonto im Google-Dienstkonto zu:

   gcloud iam service-accounts add-iam-policy-binding \
       CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/iam.serviceAccountOpenIdTokenCreator
   

   Diese Rolle bietet die Berechtigung iam.serviceAccounts.getOpenIdToken, die zum Anfordern von ID-Tokens für das Dienstkonto über die Service Account Credentials API erforderlich ist.

4. Stellen Sie eine SSH-Verbindung zur VM-Instanz her.

   gcloud compute ssh VM --tunnel-through-iap --zone ZONE
   

   Führen Sie die übrigen Befehle in diesem Abschnitt aus der SSH-Sitzung aus.

5. Erstellen Sie in der SSH-Sitzung eine Kubernetes-Clusterrollenbindung, die dem Google-Dienstkonto die Clusterrolle cluster-admin zuweist, wenn sich das Dienstkonto über den OpenID Connect-Anbieter von Google beim Cluster authentifiziert:

   kubectl create clusterrolebinding CB_GSA-cluster-admin \
       --clusterrole cluster-admin \
       --user CB_GSA@PROJECT_ID.iam.gserviceaccount.com
   

   Die Clusterrolle cluster-admin gewährt umfangreiche clusterweite Berechtigungen. In Ihrer eigenen Umgebung können Sie eine Clusterrolle verwenden, die nur die Berechtigungen enthält, die für die von Cloud Build ausgeführten Aufgaben erforderlich sind. Sie können auch Rollenbindungen verwenden, um Berechtigungen nur für bestimmte Namespaces zu gewähren.

   Wenn Sie in der ClientConfig in Ihrer eigenen Umgebung einen userPrefix festlegen, müssen Sie diesem Präfix den Wert des --user-Flags in diesem Befehl hinzufügen.

6. Verlassen Sie die SSH-Sitzung:

   exit
   

Privaten Cloud Build-Pool erstellen

1. Weisen Sie in Cloud Shell einen IP-Adressbereich in Ihrem VPC-Netzwerk für die Verbindung mit dem privaten Pool zu:

   gcloud compute addresses create RESERVED_RANGE_NAME \
   --addresses RESERVED_RANGE_START_IP\
       --description "Cloud Build private pool reserved range" \
       --global \
       --network NETWORK \
       --prefix-length RESERVED_RANGE_PREFIX_LENGTH \
       --purpose VPC_PEERING
   

   Ersetzen Sie Folgendes:

   • RESERVED_RANGE_NAME: der Name des zugewiesenen IP-Adressbereichs, der den privaten Cloud Build-Pool hostet. Verwenden Sie für diese Anleitung cloud-build-private-pool.
   • RESERVED_RANGE_START_IP: die erste IP-Adresse des zugewiesenen IP-Adressbereichs. Verwenden Sie für diese Anleitung 192.168.12.0.
   • RESERVED_RANGE_PREFIX_LENGTH: die Präfixlänge (Subnetzmaske) des zugewiesenen IP-Adressbereichs. Die Präfixlänge muss /23 oder eine niedrigere Zahl sein, z. B. /22 oder /21. Je niedriger die Zahl, desto größer der Adressbereich. Verwenden Sie für diese Anleitung 23 und geben Sie nicht den vorangehenden / (Schrägstrich) ein.

2. Erstellen Sie eine Firewallregel, die eingehenden Traffic aus dem reservierten IP-Adressbereich zu anderen Ressourcen in Ihrem VPC-Netzwerk zulässt:

   gcloud compute firewall-rules create allow-private-pools-ingress \
       --allow all \
       --network NETWORK \
       --source-ranges RESERVED_RANGE_START_IP/RESERVED_RANGE_PREFIX_LENGTH
   

3. Erstellen Sie eine private Dienstverbindung, um Ihr VPC-Netzwerk mit dem Service Networking-Dienst zu verbinden:

   gcloud services vpc-peerings connect \
       --network NETWORK \
       --ranges RESERVED_RANGE_NAME \
       --service servicenetworking.googleapis.com
   

   In privaten Cloud Build-Pools werden Worker mithilfe von Service Networking ausgeführt. Über die private Dienstverbindung kann Ihr VPC-Netzwerk über eine VPC-Netzwerk-Peering-Verbindung mit dem privaten Pool im zugewiesenen Bereich von internen IP-Adressen kommunizieren.

   Es kann einige Minuten dauern, bis die Verbindung zum privaten Dienst erstellt ist.

   Wenn Sie in Ihrer eigenen Umgebung eine freigegebene VPC verwenden, finden Sie unter Umgebung einrichten Informationen zu zusätzlichen Schritten zum Erstellen der privaten Dienstverbindung.

4. So erstellen Sie einen privaten Cloud Build-Pool in einem von Google verwalteten VPC-Netzwerk, das mit Ihrem VPC-Netzwerk verbunden ist:

   gcloud builds worker-pools create PRIVATE_POOL_NAME \
      --no-public-egress \
      --peered-network projects/PROJECT_ID/global/networks/NETWORK \
      --region REGION
   

   Ersetzen Sie Folgendes:

   • PRIVATE_POOL_NAME: der Name des privaten Pools. Verwenden Sie für diese Anleitung private-pool.
   • REGION: die Region, die für den privaten Pool verwendet werden soll. Verwenden Sie für diese Anleitung us-central1.

   Das Flag --no-public-egress bedeutet, dass die Worker im privaten Pool keine öffentlichen IP-Adressen haben. In Ihrer eigenen Umgebung können Sie dieses Flag entfernen, wenn Worker im privaten Pool eine Internetverbindung über öffentliche IP-Adressen haben sollen.

   Informationen zu zusätzlichen Konfigurationsoptionen wie Maschinentyp und Laufwerkgröße für die Worker im privaten Pool finden Sie unter Private Pools erstellen und verwalten.

Lösung prüfen

In diesem Abschnitt prüfen Sie die Lösung, indem Sie einen Build im privaten Cloud Build-Pool ausführen. Der Build greift auf den privaten GKE-Cluster zu.

1. Erstellen Sie in Cloud Shell einen Cloud Storage-Bucket zum Speichern von Build-Logs aus Cloud Build:

   gcloud storage buckets create gs://PROJECT_ID-build-logs --location=REGION
   

2. Erstellen Sie eine Build-Konfigurationsdatei für Cloud Build:

   cat << "EOF" > cloudbuild.yaml
   steps:
   - id: list-services
     name: gcr.io/google.com/cloudsdktool/google-cloud-cli
     entrypoint: bash
     args:
     - -eEuo
     - pipefail
     - -c
     - |-
       kubectl config use-context $_KUBECTL_CONTEXT
   
       ACCESS_TOKEN=$$(curl --silent \
           --header "Metadata-Flavor: Google" \
           http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token \
           | python3 -c 'import json, sys; print(json.load(sys.stdin).get("access_token"))')
   
       ID_TOKEN=$$(curl --silent --request POST \
           --data '{"audience": "CLIENT_ID", "includeEmail": true}' \
           --header "Authorization: Bearer $$ACCESS_TOKEN" \
           --header "Content-Type: application/json; charset=utf-8" \
           "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$_SERVICE_ACCOUNT:generateIdToken" \
           | python3 -c 'import json, sys; print(json.load(sys.stdin).get("token"))')
   
       kubectl get services --namespace $_NAMESPACE --token $$ID_TOKEN
   
   logsBucket: gs://PROJECT_ID-build-logs
   
   options:
     env:
     - KUBECONFIG=/workspace/$_KUBECONFIG
   
   substitutions:
     _KUBECONFIG: kubeconfig
     _KUBECTL_CONTEXT: private-cluster
     _NAMESPACE: default
   
   serviceAccount: projects/$PROJECT_ID/serviceAccounts/$_SERVICE_ACCOUNT
   EOF
   

   Der Schritt in der Build-Konfigurationsdatei führt Folgendes aus:

   1. Wechselt zum kubectl-Kontext, der durch die _KUBECTL_CONTEXT-Substitution angegeben wird. Der Standardwert für die Ersetzung ist private-cluster.

   2. Ruft ein Zugriffstoken vom Metadatenserver ab. Das Zugriffstoken wird für das Google-Dienstkonto ausgestellt, über das der Build ausgeführt wird.

   3. Generiert ein ID-Token mithilfe der Service Account Credentials API. Die Anfrage zum Generieren des ID-Tokens wird mit dem Zugriffstoken authentifiziert. Der angeforderte aud-Anspruch (Zielgruppe) des ID-Tokens ist die OAuth 2.0-Client-ID, die durch die _CLIENT_ID-Ersetzung angegeben wird.

   4. Listet die Kubernetes-Dienste im Namespace auf, der durch die _NAMESPACE-Ersetzung angegeben ist. Der Standardwert für die Ersetzung ist default. Die Anfrage wird mit dem ID-Token authentifiziert, das im vorherigen Befehl generiert wurde.

   Beachten Sie bei der Build-Konfigurationsdatei Folgendes:

   • Das Zeichen $ ist das Präfix für Ersetzungen. $$ wird für die Bash-Parametererweiterung und die Befehlssubstitution verwendet.

   • Mit den Platzhaltern _KUBECONFIG und _KUBECTL_CONTEXT können beim Ausführen eines Builds unterschiedliche kubeconfig-Dateien und unterschiedliche Kontexte angegeben werden. Mit diesen Ersetzungen können Sie mehrere Clusterkonfigurationen verwalten, indem Sie entweder eine einzelne kubeconfig-Datei mit mehreren Kontexten oder mehrere kubeconfig-Dateien verwenden.

   • Die Substitution _SERVICE_ACCOUNT hat keinen Standardwert. Sie müssen einen Wert für diese Substitution angeben, wenn Sie einen Build ausführen.

   • Im Block options wird die Umgebungsvariable KUBECONFIG für alle Schritte im Build festgelegt.

   • Für den Build-Schritt wird das gcr.io/google.com/cloudsdktool/google-cloud-cli-Builder-Image verwendet. Dies ist ein großes Container-Image und es dauert einige Zeit, bis es aus der Registry in den privaten Pool-Worker kopiert wird. Um die Zeit für das Abrufen des Builder-Images zu verkürzen, können Sie ein benutzerdefiniertes Builder-Image erstellen, das nur die für den Build-Schritt erforderlichen Tools wie curl, kubectl und Python enthält.

   Weitere Informationen zu Inline-Shell-Scripts in Build-Konfigurationsdateien finden Sie unter Bash-Scripts ausführen.

3. Führen Sie einen Build mit der Build-Konfigurationsdatei und den Dateien im aktuellen Verzeichnis aus:

   gcloud builds submit \
       --config cloudbuild.yaml \
       --region REGION \
       --substitutions _SERVICE_ACCOUNT=CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --worker-pool projects/PROJECT_ID/locations/REGION/workerPools/PRIVATE_POOL_NAME
   

   Mit dem Befehl werden alle Dateien im aktuellen Verzeichnis in Cloud Storage hochgeladen, damit sie von Cloud Build verwendet werden können. Der Build-Schritt verwendet die kubeconfig-Datei, um eine Verbindung zum GKE-Cluster herzustellen.

   Gegen Ende der Ausgabe sehen Sie Zeilen, die in etwa so aussehen:

   NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
   kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP   2h
   

   Diese Ausgabe zeigt, dass der Worker des privaten Pools über den Identity Service für den GKE-Authentifizierungs-Proxy eine Verbindung zur Cluster-Steuerungsebene hergestellt hat.

Fehlerbehebung

Wenn Sie keine SSH-Verbindung zur VM-Instanz herstellen können, fügen Sie das Flag --troubleshoot hinzu, um die Ursache der Verbindungsprobleme zu ermitteln:

gcloud compute ssh VM --tunnel-through-iap --zone ZONE --troubleshoot

Wenn Sie beim Patchen der Standard-ClientConfig im GKE-Cluster die Meldung Error from server (NotFound): clientconfigs.authentication.gke.io "default" not found erhalten, prüfen Sie, ob Sie die Firewallregel wie im Abschnitt Privaten GKE-Cluster erstellen beschrieben erstellt haben. Bestätigen Sie, dass die Firewallregel existiert:

gcloud compute firewall-rules describe allow-control-plane-clientconfig-webhook

Wenn Sie sich nicht beim Identity Service for GKE-Proxy authentifizieren können, suchen Sie in den Logs der Pods in der gke-oidc-service-Bereitstellung nach Fehlern:

gcloud compute ssh VM --tunnel-through-iap --zone ZONE --command \
    'kubectl logs deployment/gke-oidc-service \
         --namespace anthos-identity-service --all-containers'

Wenn Sie andere Probleme mit dieser Anleitung haben, empfehlen wir Ihnen, die folgenden Dokumente zu lesen:

• Fehlerbehebung für GKE
• Fehlerbehebung für Kubernetes-Cluster

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Projekt löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Ressourcen löschen

Wenn Sie das in dieser Anleitung verwendete Projekt beibehalten möchten, löschen Sie die einzelnen Ressourcen:

1. Löschen Sie den privaten Cloud Build-Pool in Cloud Shell:

   gcloud builds worker-pools delete PRIVATE_POOL_NAME --region REGION --quiet
   

2. Löschen Sie die private Dienstverbindung zum Dienstnetzwerk:

   gcloud services vpc-peerings delete --network NETWORK \
     --service servicenetworking.googleapis.com --quiet --async
   

3. Löschen Sie den IP-Adressbereich, der privaten Cloud Build-Pools zugewiesen ist:

   gcloud compute addresses delete RESERVED_RANGE_NAME --global --quiet
   

4. Löschen Sie den Cloud Storage-Bucket und seinen gesamten Inhalt:

   gcloud storage rm gs://PROJECT_ID-build-logs --recursive
   

5. Löschen Sie den GKE-Cluster:

   gcloud container clusters delete CLUSTER --zone ZONE --quiet --async
   

6. Löschen Sie die Compute Engine-VM-Instanz:

   gcloud compute instances delete VM --zone ZONE --quiet
   

7. Löschen Sie die Firewallregeln:

   gcloud compute firewall-rules delete allow-private-pools-ingress --quiet
   
   gcloud compute firewall-rules delete allow-ssh-ingress-from-iap --quiet
   
   gcloud compute firewall-rules delete allow-control-plane-clientconfig-webhook --quiet
   

8. Entfernen Sie die IAM-Rollenbindungen:

   gcloud projects remove-iam-policy-binding PROJECT_ID \
       --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/cloudbuild.builds.builder
   
   gcloud projects remove-iam-policy-binding PROJECT_ID \
       --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/container.admin
   
   gcloud iam service-accounts remove-iam-policy-binding \
       CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/iam.serviceAccountOpenIdTokenCreator
   
   gcloud iam service-accounts remove-iam-policy-binding \
       ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/iam.serviceAccountOpenIdTokenCreator
   

9. Löschen Sie die Google-Dienstkonten:

   gcloud iam service-accounts delete CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
      --quiet
   
   gcloud iam service-accounts delete ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
      --quiet
   

OAuth 2.0-Client-ID löschen

1. Rufen Sie in der Google Cloud Console die Seite Anmeldedaten auf:

   Öffnen Sie die Seite Anmeldedaten

2. Wählen Sie Ihr Projekt in der Projektauswahl aus.

3. Suchen Sie in der Tabelle OAuth 2.0-Client-IDs die Zeile für Identity Service for GKE und klicken Sie dann auf das Symbol OAuth-Client löschen.

4. Klicken Sie im Dialogfeld auf Löschen.

Nächste Schritte

• Weitere Informationen zum Zugriff auf Anthos-Cluster über Cloud Build mit dem Connect-Gateway
• Informationen zum Zugriff auf private GKE-Cluster mit privaten Cloud Build-Pools über Cloud VPN
• Weitere Informationen zum Erstellen privater GKE-Cluster mit Netzwerk-Proxys für den Zugriff auf die Steuerungsebene
• Weitere Informationen zum Zugriff auf externe Ressourcen in einem privaten Netzwerk mit einer statischen externen IP-Adresse
• Weitere Informationen zu GKE Identity Service Mit GKE Identity Service können Sie die Authentifizierung externer Identitätsanbieter für eine Flotte von Anthos-Clustern verwalten.