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. Es wird davon ausgegangen, dass Sie mit GKE, Cloud Build, OpenID Connect und gcloud vertraut sind. Befehlszeilentool.

Private Cloud Build-Pools und GKE-Cluster-Steuerungsebenen werden beide in Google-eigenen VPC-Netzwerken (Virtual Private Cloud) ausgeführt. Diese VPC-Netzwerke werden mit Ihrem eigenen VPC-Netzwerk in Google Cloud per Peering verbunden. VPC-Netzwerk-Peering unterstützt jedoch kein transitives Peering, was eine Einschränkung darstellen kann, wenn Sie private Cloud Build-Pools verwenden. In dieser Anleitung wird eine Lösung vorgestellt, bei der Identity Service for GKE verwendet wird, um Workern in einem privaten Cloud Build-Pool den Zugriff auf die Steuerungsebene eines privaten GKE-Cluster zu ermöglichen.

Architektur

Identity Service for GKE ist ein Authentifizierungsproxy 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 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. ü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 im 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.

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 im privaten Cloud Build-Pool ausgeführte Build 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 Architektur, die im vorherigen Text beschrieben wurde:

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

Die 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 (Role-based Access Control, RBAC) von Kubernetes, um die 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: der 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 Subnetz, mit dem die Steuerungsebene des GKE-Cluster eine Verbindung herstellt. Das Subnetz muss zu dem VPC-Netzwerk gehören, das durch NETWORK angegeben wird. 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 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 in einem vorhandenen Cluster aktivieren.

   • Das Flag --enable-private-endpoint konfiguriert die Steuerungsebene so, dass sie zugänglich ist mit internen IP-Adressen.

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

   • Die Flags --enable-master-authorized-networks und --enable-private-nodes den Zugriff auf den API-Server nur von den privaten Netzwerken aus zulassen, die durch das Flag --network angegeben werden.

   • Das optionale Flag --workload-pool aktiviert die Workload Identity-Föderation für GKE. Für diese Anleitung ist er nicht erforderlich.

2. Firewallregel hinzufügen, die die GKE-Clustersteuerung zulässt Ebene, um 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 (CRD), den Identity Service for GKE zum Konfigurieren verwendet mit Identitätsanbietern interagieren können.

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 für das Google Cloud-Projekt noch nicht konfiguriert wurde, klicken Sie auf Zustimmungsbildschirm konfigurieren. Folgen Sie der Dokumentation 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, Nutzersupport-E-Mail 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. In dieser Anleitung Identity Service for GKE verwenden.

6. Klicken Sie auf Erstellen.

   Ein Dialogfeld wird angezeigt. Kopiere den Wert von Meine Client-ID. Sie benötigen sie 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 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 namens client-config-patch.yaml mit Werte, die Sie später benötigen, um den Identity Service für die GKE ClientConfig-Ressource zu patchen:

   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 dem Patch:

   • ID-Tokens, die vom OAuth 2.0-Authentifizierungssystem von Google ausgestellt werden, enthalten eine eindeutige numerische Kennung in der Subjekt-Anforderung. Wenn Sie diese intransparente Kennung in Rollenbindungen verwenden, ist es schwierig, das Thema einer Rollenbindung zu identifizieren. Mit diesem Patch wird der Identitätsdienst für GKE so konfiguriert, dass die E-Mail-Anforderung aus den ID-Tokens zur Identifizierung von Nutzern verwendet wird, statt die standardmäßige untergeordnete Anforderung zu verwenden.

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

   • Die Felder cloudConsoleRedirectURI, extraParams, kubectlRedirectURI und Bereichsbereiche 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 mit dem 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 zum Authentifizieren von Google-Dienstkonten und einen anderen Identitätsanbieter zum Authentifizieren 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.

   Sie weisen dieses Google-Dienstkonto einer Compute Engine-VM-Instanz zu, um Identity Service for GKE und die rollenbasierte Zugriffssteuerung für 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:

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

Identity Service for GKE konfigurieren

Zum Konfigurieren von Identity Service for GKE müssen Sie Zugriff auf die Steuerungsebene des Clusters haben. 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. Um den authentifizierten und autorisierten SSH-Zugriff von außerhalb des VPC-Netzwerk 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 die 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 zuzugreifen.

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

   • Mit dem optionalen Metadatenwert enable-oslogin für die Instanz wird OS Login auf der VM-Instanz aktiviert. OS Login ermöglicht 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 zu trafficken über IAP verfügbar.

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

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

   Die übrigen Befehle in diesem Abschnitt führen Sie in der SSH-Sitzung aus.

5. Installieren Sie das kubectl-Befehlszeilentool und das Binärdatei "gke-gcloud-auth-plugin" 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 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 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 ClientConfig-Standardressource und speichern Sie es in einer Datei mit dem Namen 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 auf dem Cluster korrekt eingerichtet wurde. Bestätigung Ihrer Identität die Einrichtung mithilfe des an die VM-Instanz angehängten Google-Dienstkontos zur Authentifizierung beim Cluster mit Identity Service for GKE.

1. Gewähren Sie in Cloud Shell dem Google-Dienstkonto den OpenID Connect Identity Token Creator des Dienstkontos:

   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 von der 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
   

   Die übrigen Befehle in diesem Abschnitt führen Sie in 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 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. In dem Befehl wird ein Python-Inline-Skript verwendet, 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 mit der VM-Instanz verbunden 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-Anfragetext gibt den angeforderten aud-Anspruch (Zielgruppe) des ID-Tokens an.
   • Das Zugriffstoken aus dem vorherigen Schritt wird zur Authentifizierung bei der API verwendet.

5. Sehen Sie sich die Anforderungen 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 IAM-Berechtigungen nicht, wenn Sie sich mit Identity Service for 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 mithilfe des OpenID Connect-Anbieters 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. 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-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 werden, um über Cloud Build eine Verbindung zum GKE-Cluster herzustellen:

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

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

   Dieser Befehl verwendet den Namen des GKE-Cluster als Clusterkonfigurationsnamen für den Kontext. In Ihrer eigenen Umgebung können Sie einen anderen Namen für die Clusterkonfiguration im Kontext 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 Cloud Shell ein Google-Dienstkonto, um Builds auf dem Privater Cloud Build-Pool:

   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. Gewähren Sie dem Dienstkonto selbst den OpenID Connect Identity Token Creator des Dienstkontos im Google-Dienstkonto:

   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 von der 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
   

   Die übrigen Befehle in diesem Abschnitt führen Sie in 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 mithilfe des OpenID Connect-Anbieters 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 umfassende 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 eine 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 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, in dem der private Cloud Build-Pool gehostet wird. 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. Eine niedrigere Zahl bedeutet einen größeren Adressbereich. Verwenden Sie für diese Anleitung 23 und geben Sie nicht den vorangestellten / (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 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 mithilfe von Service Networking ausgeführt. Die private Dienstverbindung ermöglicht Ihrem VPC-Netzwerk die Kommunikation mit dem privaten Pool über den zugewiesenen Bereich von internen IP-Adressen über eine VPC-Netzwerk-Peering-Verbindung.

   Es kann einige Minuten dauern, bis die private Dienstverbindung 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. Erstellen Sie einen privaten Cloud Build-Pool in einem Google-eigenen VPC-Netzwerk, 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 ist 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. Sie können dieses Flag in Ihrer eigenen Umgebung entfernen, wenn Sie möchten, dass Worker im privaten Pool über öffentliche IP-Adressen eine Internetverbindung herstellen.

   Informationen zu zusätzlichen Konfigurationsoptionen, z. B. 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 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 Standardersetzungswert 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. 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 Ersetzung _CLIENT_ID angegeben wird.

   4. Listet die Kubernetes-Dienste im Namespace auf, der durch die Substitution _NAMESPACE 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 Folgendes zur Build-Konfigurationsdatei:

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

   • Mit den Substitutionen _KUBECONFIG und _KUBECTL_CONTEXT können verschiedene kubeconfig-Dateien und verschiedene Kontexte angegeben werden, wenn Sie einen Build ausführen. 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 einen Wert für diese Substitution angeben, wenn Sie einen Build ausführen.

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

   • 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, das einige Zeit in Anspruch nimmt, um es aus der Registry in den Worker des privaten Pools abzurufen. Um die Zeit zum 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 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, die sich im aktuellen Verzeichnis befinden, zur Verwendung durch Cloud Build in Cloud Storage hochgeladen. Der Build-Schritt verwendet die kubeconfig-Datei, um eine Verbindung zum GKE-Cluster herzustellen.

   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 der private Pool-Worker über den Authentifizierungsproxy Identity Service for GKE eine Verbindung zur Steuerungsebene des Clusters hergestellt 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 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 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 andere Probleme mit dieser Anleitung 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.

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

3. Suchen Sie in der Tabelle OAuth 2.0 Client-IDs die Zeile 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

• Mit dem Verbindungsgateway aus Cloud Build auf Anthos-Cluster zugreifen
• Informationen zum Zugriff auf private GKE-Cluster mit privaten Cloud Build-Pools über Cloud VPN
• 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
• Weitere Informationen zum GKE Identity Service Mit dem GKE Identity Service können Sie die Authentifizierung externer Identitätsanbieter für eine Flotte von Anthos-Cluster verwalten.