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.

Diese Lösung ermöglicht mithilfe des Identity Service for GKE-Proxys 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 im privaten Cloud Build-Pool ausgeführte Build wird als Google-Dienstkonto ausgeführt. Dieses Google-Dienstkonto kann ein ID-Token abrufen, um sich über die Service Account Credentials API beim Proxy zu authentifizieren.

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

Mit Identity Service for GKE auf private GKE-Cluster zugreifen

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. 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. Create or select a Google Cloud 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. 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.
  7. Installieren Sie die Google Cloud CLI.

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

    gcloud init

  9. Create or select a Google Cloud 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. 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
    12.

Privaten GKE-Cluster erstellen

  1. Erstellen Sie in Cloud Shell einen GKE-Cluster ohne Client Zugriff auf den öffentlichen Endpunkt der Steuerungsebene, auf 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. 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 Workload Identity. 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, E-Mail-Adresse des Nutzersupports und Kontaktdaten des Entwicklers sind erforderlich und können einen beliebigen Wert haben.
    • Für diese Anleitung müssen Sie keine Bereiche hinzufügen.

    Wenn Sie die Konfiguration des Zustimmungsbildschirms abgeschlossen haben, 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 in das 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, sodass die ausgestellten ID-Tokens den E-Mail-Anspruch 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 des 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. Kubernetes Engine-Administrator gewähren dem Google-Dienstkonto die Rolle 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 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. 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). 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 über TCP-Weiterleitung von IAP zu allen VM-Instanzen mit dem Netzwerk-Tag ssh-iap:

    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 das Dienstkonto zuzugreifen Credentials API

    • 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 enable-oslogin-Instanzmetadatenwert aktiviert OS Login auf der VM-Instanz. 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 ClientConfig-Standardressource 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 die angeforderte aud-Anforderung (Audience) 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 Flags --user 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

Mit dem Befehl kubectl kann der Zugriff auf Cluster mit einer Datei der Binärdatei konfiguriert werden. Eine kubeconfig-Datei enthält einen oder mehrere Kontexte. Jeder Kontext hat einen Namen und enthält optional Informationen zur Clusterverbindung, Anmeldedaten, die zur Authentifizierung beim Cluster verwendet werden, 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 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 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. Das Präfix 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, um eingehenden Traffic vom 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 mithilfe von Service Networking ausgeführt. Die private Dienstverbindung ermöglicht Ihrem VPC-Netzwerk die Kommunikation mit dem privaten Pool über den zugewiesenen Bereich interner 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 weiteren 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 Pool von Cloud Build 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 folgende Schritte aus:

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

    2. Ruft ein Zugriffstoken vom Metadatenserver ab. Das Zugriffstoken wird an das Google-Dienstkonto ausgegeben, mit dem 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 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 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.

    • Im 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 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. Im Build-Schritt wird die Datei "Datei" verwendet, 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 des 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 erstellt haben, wie im Abschnitt Privaten GKE-Cluster erstellen beschrieben. 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:

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

    Google Cloud-Projekt löschen:

    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 in Cloud Shell den privaten Pool von Cloud Build:

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