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

---

In dieser Anleitung wird beschrieben, wie Sie mithilfe von privaten Cloud Build-Pools auf die Steuerungsebene eines privaten GKE-Clusters (Google Kubernetes Engine) zugreifen. Mit diesem Zugriff können Sie Cloud Build zum Bereitstellen von Anwendungen und Verwalten von Ressourcen in einem privaten GKE-Cluster verwenden. 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 in VPC-Netzwerken (Virtual Private Cloud) von Google ausgeführt. Diese VPC-Netzwerke werden mit Ihrem eigenen VPC-Netzwerk in Google Cloud durch Peering verbunden. Das VPC-Netzwerk-Peering unterstützt jedoch kein transitives Peering, das eine Einschränkung bei der Verwendung privater Cloud Build-Pools darstellen kann. In dieser Anleitung wird eine Lösung vorgestellt, bei der Worker in einem privaten Cloud Build-Pool mithilfe von Identity Service for GKE auf die Steuerungsebene eines privaten GKE-Cluster zugreifen können.

Architektur

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

Der Identity Service for GKE-Proxy wird als Pods auf Clusterknoten ausgeführt. Ein Kubernetes-Dienst vom Typ LoadBalancer macht den Proxy außerhalb des Clusters verfügbar. Wenn Identity Service for GKE in einem privaten Cluster aktiviert ist, fügt das Installationsprogramm eine Annotation zum Kubernetes-Dienst hinzu, um einen internen Passthrough-Network Load Balancer bereitzustellen. Der Zugriff auf den Proxy ist über den Load-Balancer über eine VPC-Netzwerk-Peering-Verbindung möglich, z. B. über einen privaten Cloud Build-Pool, da der Proxy auf Clusterknoten in Ihrem VPC-Netzwerk ausgeführt wird.

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

In Kombination ermöglicht diese Lösung über den Identity Service for GKE-Proxy den Zugriff auf die Steuerungsebene des privaten GKE-Cluster. 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 ein ID-Token abrufen, um sich von der Service Account Credentials API beim Proxy zu authentifizieren.

Das folgende Diagramm zeigt die Architektur, die im vorherigen Text beschrieben wurde:

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

IAM-Berechtigungen (Identity and Access Management) für Nutzerkonten und Google-Dienstkonten gelten nicht für die Authentifizierung mit Identity Service for GKE. Stattdessen verwenden Sie die rollenbasierte Zugriffssteuerung von Kubernetes (Role-based Access Control, RBAC), um Clusterberechtigungen für diese Konten zu verwalten.

Hinweise

1. Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.
2. Installieren Sie die Google Cloud CLI.

3. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

   gcloud init

4. Google Cloud-Projekt erstellen oder auswählen.

   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

   • Erstellen Sie ein Google Cloud-Projekt:

     gcloud projects create PROJECT_ID

     Ersetzen Sie PROJECT_ID durch einen Namen für das Google Cloud-Projekt, das Sie erstellen.

   • Wählen Sie das von Ihnen erstellte Google Cloud-Projekt aus:

     gcloud config set project PROJECT_ID

     Ersetzen Sie PROJECT_ID durch den Namen Ihres Google Cloud-Projekts.

5. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

6. Aktivieren Sie die 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. Installieren Sie die Google Cloud CLI.

8. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

   gcloud init

9. Google Cloud-Projekt erstellen oder auswählen.

   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

   • Erstellen Sie ein Google Cloud-Projekt:

     gcloud projects create PROJECT_ID

     Ersetzen Sie PROJECT_ID durch einen Namen für das Google Cloud-Projekt, das Sie erstellen.

   • Wählen Sie das von Ihnen erstellte Google Cloud-Projekt aus:

     gcloud config set project PROJECT_ID

     Ersetzen Sie PROJECT_ID durch den Namen Ihres Google Cloud-Projekts.

10. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

11. Aktivieren Sie die 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, der keinen Clientzugriff auf den öffentlichen Endpunkt der Steuerungsebene hat und bei dem Identity Service for GKE installiert ist:

   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: der IP-Adressbereich der Steuerungsebene. Er 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 eine Verbindung herstellt. Verwenden Sie für diese Anleitung default.
   • SUBNET: das Subnetz, mit dem die Steuerungsebene des GKE-Cluster verbunden ist. Das Subnetz muss zu dem in NETWORK angegebenen VPC-Netzwerk gehören. Verwenden Sie für diese Anleitung default.
   • NODE_TAGS: eine durch Kommas getrennte Liste von Netzwerktags, die auf die Knoten angewendet werden sollen. Verwenden Sie für diese Anleitung private-cluster-node.
   • PROJECT_ID ist 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:

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

   • Das Flag --enable-private-endpoint konfiguriert die Steuerungsebene so, dass sie nur über interne IP-Adressen zugänglich ist.

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

   • Die Flags --enable-master-authorized-networks und --enable-private-nodes ermöglichen den Zugriff auf den API-Server nur aus den privaten Netzwerken, die mit dem Flag --network angegeben werden.

   • Das optionale Flag --workload-pool aktiviert Workload Identity. Es ist für diese Anleitung nicht erforderlich.

2. Fügen Sie eine Firewallregel hinzu, die es der Steuerungsebene des GKE-Cluster ermöglicht, eine Verbindung zum validierenden Zulassungs-Webhook für ClientConfig-Ressourcen herzustellen:

   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 (Custom Resource Type, CRD), mit dem Identity Service for GKE die Interaktion mit Identitätsanbietern konfiguriert.

Identity Service for GKE als OAuth 2.0-Clientanwendung registrieren

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

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 Zustimmungsbildschirm noch nicht für das Google Cloud-Projekt konfiguriert wurde, klicken Sie auf Zustimmungsbildschirm konfigurieren. Folgen Sie der Anleitung zum Konfigurieren des Zustimmungsbildschirms. Legen Sie für diese Anleitung die folgenden Werte fest:

   • Nutzertyp kann entweder Intern oder Extern sein. Für diese Anleitung können Sie „Intern“ auswählen.
   • Die Werte für App-Name, E-Mail-Adresse des Nutzersupports und Kontaktdaten des Entwicklers sind erforderlich und können einen beliebigen Wert haben.
   • Sie müssen für diese Anleitung keine Bereiche hinzufügen.

   Wenn Sie mit der Konfiguration des Zustimmungsbildschirms fertig sind, klicken Sie auf „Zurück zum Dashboard“ und beginnen Sie noch einmal mit Schritt 1 des aktuellen Verfahrens.

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 Your Client ID (Meine 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 unter Ihrem Basisverzeichnis ein Verzeichnis namens cloud-build-private-pools-gke-tutorial und rufen Sie dieses Verzeichnis auf:

   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 der Identity Service for GKE-Ressource "ClientConfig" 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 zum Patch:

   • ID-Tokens, die über das OAuth 2.0-Authentifizierungssystem von Google ausgestellt werden, enthalten im Subjekt-Anspruch eine eindeutige numerische Kennung. Wenn Sie diese intransparente Kennung in Rollenbindungen verwenden, ist es schwierig, das Thema einer Rollenbindung zu identifizieren. Mit diesem Patch wird Identity Service for GKE daher so konfiguriert, dass zur Identifizierung von Nutzern die E-Mail-Anforderung aus den ID-Tokens verwendet wird, anstatt die standardmäßige untergeordnete Anforderung zu verwenden.

   • Der E-Mail-Bereich wird hinzugefügt, sodass die ausgestellten ID-Tokens den E-Mail-Anspruch enthalten.

   • Die Felder cloudConsoleRedirectURI, extraParams, kubectlRedirectURI und Bereiche werden verwendet, wenn Entwickler sich mit Identity Service for GKE beim Cluster authentifizieren. Sie werden nicht verwendet, wenn sich Google-Dienstkonten beim Cluster authentifizieren. Das Feld "kubectlWeiterleitungURI" ist obligatorisch.

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

   • Das Feld spec.authentication ist ein Array. Sie können mehrere OpenID Connect-Identitätsanbieter mit Identity Service for GKE verwenden. Beispielsweise können Sie Google als Identitätsanbieter zur Authentifizierung von Google-Dienstkonten und einen anderen Identitätsanbieter zur Authentifizierung von Entwicklern verwenden.

   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.

   Weisen Sie dieses Google-Dienstkonto einer Compute Engine-VM-Instanz zu, um Identity Service for GKE und die rollenbasierte Zugriffssteuerung von Kubernetes auf dem 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 stellt die Berechtigungen bereit, die zum Ausführen der folgenden Aufgaben in dieser Anleitung erforderlich sind:

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

Identity Service for GKE konfigurieren

Zum Konfigurieren von Identity Service for GKE benötigen Sie Zugriff auf die Steuerungsebene des Clusters. In dieser Anleitung erstellen Sie eine Compute Engine-VM-Instanz für den Zugriff auf die Steuerungsebene.

Sie benötigen SSH-Zugriff auf die VM-Instanz. Verwenden Sie die TCP-Weiterleitung mit Identity-Aware Proxy (IAP), um den authentifizierten und autorisierten SSH-Zugriff von außerhalb des VPC-Netzwerk auf die VM-Instanz zu aktivieren. Dieses Feature ermöglicht den SSH-Zugriff, ohne dass die VM-Instanz eine öffentliche IP-Adresse haben muss.

1. Erstellen Sie in Cloud Shell eine Firewallregel, die den SSH-Zugriff mit der 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 zum obigen Befehl 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 zugreifen zu können.

   • Der Bereich userinfo-email ist hilfreich beim Erstellen einer VM-Instanz zum Verwalten der rollenbasierten Kubernetes-Zugriffssteuerung. Er ist für diese Anleitung optional.

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

   • Der optionale Metadatenwert enable-oslogin der Instanz aktiviert OS Login auf der VM-Instanz. OS Login aktiviert die Verwaltung des SSH-Zugriffs auf VM-Instanzen mithilfe von IAM.

3. Kopieren Sie die ClientConfig-Patchdatei 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 getunneln.

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

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

   Die restlichen Befehle in diesem Abschnitt führen Sie über die SSH-Sitzung aus.

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

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

6. Rufen Sie 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 Standardressource "ClientConfig":

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

8. Extrahieren Sie das Feld certificateAuthorityData aus der gepatchten Standardressource „ClientConfig“ 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 Standardressource "ClientConfig" 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 korrekt auf dem Cluster eingerichtet wurde. Sie prüfen die Einrichtung mithilfe des Google-Dienstkontos, das an die VM-Instanz angehängt ist, um sich mit Identity Service for GKE beim Cluster zu authentifizieren.

1. Weisen Sie in Cloud Shell dem Dienstkonto selbst die Rolle Service Account OpenID Connect Identity Token Creator für das Google-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 stellt die Berechtigung iam.serviceAccounts.getOpenIdToken bereit, die erforderlich ist, um ID-Tokens für das Dienstkonto von der Service Account Credentials API anzufordern.

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

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

   Die restlichen Befehle in diesem Abschnitt führen Sie über die SSH-Sitzung aus.

3. Fordern Sie vom Metadatenserver ein OAuth 2.0-Zugriffstoken für das Google-Dienstkonto an, das an die VM-Instanz angehängt ist. Verwenden Sie die OAuth-Client-ID als angeforderte aud-Anforderung (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 des Metadatenservers ist ein JSON-Dokument. Der Befehl verwendet ein Inline-Python-Skript, um das Feld access_token aus dem Antworttext zu extrahieren.

4. Fordern Sie von der Service Account Credentials API ein ID-Token für das Google-Dienstkonto an, das an die VM-Instanz angehängt 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 zum obigen Befehl Folgendes:

   • Das Feld audience im JSON-Requesttext gibt die angeforderte aud-Anforderung (Zielgruppe) des ID-Tokens an.
   • Das Zugriffstoken aus dem vorherigen Schritt wird zur Authentifizierung bei der API verwendet.

5. Sehen Sie sich die Ansprüche im ID-Token an:

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

   Prüfen Sie, ob die email-Anforderung 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. Obwohl dem Google-Dienstkonto IAM-Berechtigungen für GKE-Cluster im Projekt gewährt wurden, gelten bei der Authentifizierung mit Identity Service for GKE keine IAM-Berechtigungen. Stattdessen konfigurieren Sie den Zugriff mithilfe der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes.

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

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

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

8. 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

Für den Befehl kubectl kann eine kubeconfig-Datei verwendet werden, 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 zur 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-Proxys für Ihren Cluster. Sie fügen der kubeconfig-Datei keine Nutzeranmeldedaten hinzu.

1. Kopieren Sie in Cloud Shell die Dateien mit den Daten der Zertifizierungsstelle und der Server-URL von 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, die Sie später verwenden, um von Cloud Build aus eine Verbindung zum GKE-Cluster herzustellen:

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

   Das Flag --kubeconfig erstellt den Kontext und die Clusterkonfiguration in einer neuen Datei namens „kubeconfig“ im aktuellen Verzeichnis.

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

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

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

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

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

Google-Dienstkonto für Cloud Build erstellen

1. Erstellen Sie in Cloud Shell ein Google-Dienstkonto, um Builds im privaten Pool von Cloud Build 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 stellt die Standardberechtigungen des von Google verwalteten Cloud Build-Dienstkontos bereit.

3. Weisen Sie dem Dienstkonto selbst die Rolle Service Account OpenID Connect Identity Token Creator für das 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 stellt die Berechtigung iam.serviceAccounts.getOpenIdToken bereit, die erforderlich ist, um ID-Tokens für das Dienstkonto von der Service Account Credentials API anzufordern.

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

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

   Die restlichen Befehle in diesem Abschnitt führen Sie über die 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 mit dem 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 Berechtigungen für den gesamten Cluster. In Ihrer eigenen Umgebung können Sie eine Clusterrolle verwenden, die nur die Berechtigungen gewährt, 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 ein userPrefix in der ClientConfig in Ihrer eigenen Umgebung festlegen, müssen Sie dieses Präfix dem Wert des Flags --user in diesem Befehl hinzufügen.

6. Verlassen Sie die SSH-Sitzung:

   exit
   

Privaten Cloud Build-Pool erstellen

1. Weisen Sie in Cloud Shell für die Verbindung mit dem privaten Pool einen IP-Adressbereich in Ihrem VPC-Netzwerk 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 führenden / (Schrägstrich) ein.

2. Erstellen Sie eine Firewallregel, um eingehenden Traffic aus dem reservierten IP-Adressbereich zu anderen Ressourcen in Ihrem VPC-Netzwerk zuzulassen:

   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 Dienstnetzwerkdienst zu verbinden:

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

   In privaten Cloud Build-Pools werden Worker über das Dienstnetzwerk ausgeführt. Die private Dienstverbindung ermöglicht Ihrem VPC-Netzwerk, über eine VPC-Netzwerk-Peering-Verbindung mit dem privaten Pool im zugewiesenen Bereich interner IP-Adressen zu kommunizieren.

   Das Erstellen der privaten Dienstverbindung kann einige Minuten dauern.

   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. Erstellen Sie einen privaten Cloud Build-Pool in einem VPC-Netzwerk von Google, das über Peering 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 Worker im privaten Pool keine öffentlichen IP-Adressen haben. In Ihrer eigenen Umgebung können Sie dieses Flag entfernen, wenn die Worker im privaten Pool eine Internetverbindung über öffentliche IP-Adressen haben sollen.

   Informationen zu zusätzlichen Konfigurationsoptionen wie Maschinentyp und Laufwerksgröß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, um Build-Logs aus Cloud Build zu speichern:

   gsutil mb -l REGION gs://PROJECT_ID-build-logs
   

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 umfasst Folgendes:

   1. Wechselt zum kubectl-Kontext, der durch die _KUBECTL_CONTEXT-Substitution angegeben wird. Der Standardersetzungswert ist private-cluster.

   2. Ruft ein Zugriffstoken vom Metadatenserver ab. Das Zugriffstoken wird an das Google-Dienstkonto ausgegeben, das den Build ausführt.

   3. Erzeugt mithilfe der Service Account Credentials API ein ID-Token. Die Anfrage zum Generieren des ID-Tokens wird mithilfe des Zugriffstokens authentifiziert. Die angeforderte aud-Anforderung (Zielgruppe) des ID-Tokens ist die OAuth 2.0-Client-ID, die durch die _CLIENT_ID-Substitution angegeben wird.

   4. Listet die Kubernetes-Dienste in dem Namespace auf, der durch die Substitution _NAMESPACE angegeben wird. Der Standardersetzungswert ist default. Die Anfrage wird mithilfe des ID-Tokens authentifiziert, das im vorherigen Befehl generiert wurde.

   Beachten Sie Folgendes zur Build-Konfigurationsdatei:

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

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

   • Die Ersetzung _SERVICE_ACCOUNT hat keinen Standardwert. Sie müssen beim Ausführen eines Builds einen Wert für diese Substitution angeben.

   • Der Block options legt die Umgebungsvariable KUBECONFIG für alle Schritte im Build fest.

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

   Weitere Informationen zu Inline-Shell-Skripts in Build-Konfigurationsdateien finden Sie unter Bash-Skripts 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 zur Verwendung von Cloud Build in Cloud Storage hochgeladen. Im Build-Schritt wird mithilfe der kubeconfig-Datei eine Verbindung zum GKE-Cluster hergestellt.

   Am 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 sich der private Pool-Worker über den Authentifizierungs-Proxy von Identity Service for GKE mit der Steuerungsebene des Clusters verbunden hat.

Fehlerbehebung

Wenn Sie über SSH keine 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 standardmäßigen 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 Private 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 im gke-oidc-service-Deployment 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 im Rahmen dieser Anleitung andere Probleme auftreten, 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.

Google Cloud-Projekt löschen:

gcloud projects delete PROJECT_ID

Ressourcen löschen

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

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

   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:

   gsutil rm -r gs://PROJECT_ID-build-logs
   

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 aus der Projektauswahlliste aus.

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

4. Klicken Sie im Dialogfeld auf Löschen.

Nächste Schritte

• Mit dem Connect-Gateway über Cloud Build auf Anthos-Cluster zugreifen
• Über Cloud VPN mit privaten Cloud Build-Pools auf private GKE-Cluster zugreifen
• Private GKE-Cluster mit Netzwerk-Proxys für den Zugriff auf die Steuerungsebene erstellen
• Mit einer statischen externen IP-Adresse auf externe Ressourcen in einem privaten Netzwerk zugreifen
• GKE Identity Service kennenlernen Mit GKE Identity Service können Sie die Authentifizierung externer Identitätsanbieter für eine Reihe von Anthos-Cluster verwalten.