Workload Identity verwenden

In diesem Dokument wird gezeigt, wie Sie Workload Identity in Ihren GKE-Clustern (Google Kubernetes Engine) aktivieren und konfigurieren. Workload Identity ermöglicht Arbeitslasten in Ihren GKE-Clustern, die Identität von Identity and Access Management (IAM)-Dienstkonten für den Zugriff auf Google Cloud-Dienste anzunehmen.

Weitere Informationen zur Funktionsweise von Workload Identity finden Sie unter Workload Identity.

Beschränkungen

  • GKE erstellt für jedes Google Cloud-Projekt einen festen Workload Identity-Pool im Format PROJECT_ID.svc.id.goog.

  • Workload Identity macht die Verwendung der Metadatenverbergung überflüssig. Die vertraulichen Metadaten, die durch Metadatenverbergung geschützt werden, werden durch Workload Identity ebenfalls geschützt.

  • Wenn GKE den GKE-Metadatenserver in einem Knotenpool aktiviert, können Pods nicht mehr auf den Compute Engine-Metadatenserver zugreifen. Stattdessen fängt der GKE-Metadatenserver Anfragen von diesen Pods an Metadatenendpunkte ab, mit Ausnahme von Pods, die im Hostnetzwerk ausgeführt werden.

  • Workload Identity kann nicht mit Pods verwendet werden, die im Hostnetzwerk ausgeführt werden. Anfragen von diesen Pods an Metadaten-Endpunkte werden an den Compute Engine-Metadatenserver weitergeleitet.

  • Es dauert einige Sekunden, bis der GKE-Metadatenserver Anfragen für einen neu erstellten Pod akzeptiert. Daher können Versuche, sich mit Workload Identity innerhalb der ersten Sekunden eines Pods zu authentifizieren, fehlschlagen. Wiederholen Sie den Aufruf, um das Problem zu beheben. Weitere Informationen finden Sie im Abschnitt zur Fehlerbehebung.

  • In GKE integrierte Logging- und Monitoring-Agents verwenden weiterhin das Dienstkonto des Knotens.

  • Workload Identity erfordert ein manuelles Einrichten von Cloud Run for Anthos, damit weiterhin Anfragemesswerte freigegeben werden können.

  • Workload Identity installiert ip-masq-agent, wenn der Cluster ohne das Flag --disable-default-snat erstellt wird.

  • Workload Identity legt ein Limit von 200 Verbindungen zum GKE-Metadatenserver für jeden Knoten fest, um Arbeitsspeicherprobleme zu vermeiden. Wenn Ihre Knoten dieses Limit überschreiten, können Zeitüberschreitungen auftreten.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Achten Sie darauf, dass die Google Kubernetes Engine API aktiviert ist.
  • Google Kubernetes Engine API aktivieren
  • Prüfen Sie, ob das Cloud SDK installiert ist.
  • Mit den folgenden Methoden können Sie die Standardeinstellungen für das gcloud-Befehlszeilentool für Ihr Projekt einrichten:
    • Verwenden Sie gcloud init, wenn Sie die erforderlichen Standardeinstellungen für Projekte festlegen möchten.
    • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

    gcloud init

    1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

      gcloud init

      Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

      gcloud init --console-only
    2. Folgen Sie der Anleitung, um das gcloud-Tool zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
    3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
    4. Wählen Sie ein Google Cloud-Projekt aus.
    5. Wählen Sie eine Compute Engine-Standardzone aus.
    6. Wählen Sie eine Compute Engine-Standardregion aus.

    gcloud config

    1. Legen Sie Ihre standardmäßige Projekt-ID fest:
      gcloud config set project PROJECT_ID
    2. Legen Sie Ihre standardmäßige Compute Engine-Region fest (z. B. us-central1):
      gcloud config set compute/region COMPUTE_REGION
    3. Legen Sie Ihre standardmäßige Compute Engine-Zone fest (z. B. us-central1-c):
      gcloud config set compute/zone COMPUTE_ZONE
    4. Aktualisieren Sie gcloud auf die neueste Version:
      gcloud components update

    Durch Festlegen von Standardspeicherorten können Sie Fehler im gcloud-Tool wie die folgenden vermeiden: One of [--zone, --region] must be supplied: Please specify location.

  • Achten Sie darauf, dass die IAM Service Account Credentials API aktiviert ist.

    IAM Credentials API aktivieren

  • Prüfen Sie, ob Sie die folgenden IAM-Rollen haben:

    • roles/container.admin
    • roles/iam.serviceAccountAdmin

Workload Identity in einem Cluster aktivieren

Sie können Workload Identity in einem neuen oder vorhandenen GKE Standardcluster mithilfe des gcloud-Tools aktivieren. Workload Identity ist auf GKE Autopilot-Clustern standardmäßig aktiviert.

  1. Achten Sie darauf, dass die IAM Service Account Credentials API aktiviert ist.

    IAM Credentials API aktivieren

  2. Erstellen Sie mit dem folgenden Befehl einen neuen Cluster mit aktiviertem Workload Identity:

    gcloud container clusters create CLUSTER_NAME \
        --workload-pool=PROJECT_ID.svc.id.goog
    

    Dabei gilt:

    • CLUSTER_NAME ist der Name Ihres Clusters.
    • PROJECT_ID ist die ID Ihres Google Cloud-Projekts.
  3. Ändern Sie den Cluster mit dem folgenden Befehl, um Workload Identity für einen vorhandenen Cluster zu aktivieren:

    gcloud container clusters update CLUSTER_NAME \
        --workload-pool=PROJECT_ID.svc.id.goog
    

    Vorhandene Knotenpools sind davon nicht betroffen. Neue Knotenpools sind standardmäßig auf --workload-metadata=GKE_METADATA eingestellt.

Anwendungen zu Workload Identity migrieren

Wählen Sie die für Ihre Umgebung am besten geeignete Migrationsstrategie aus. Knotenpools können unverändert migriert werden oder Sie können neue Knotenpools mit aktiviertem Workload Identity erstellen. Es ist empfehlenswert, neue Knotenpools zu erstellen, wenn Sie Ihre Anwendung ebenfalls ändern müssen, damit sie mit diesem Feature kompatibel ist.

Fügen Sie dem Cluster einen neuen Knotenpool mit aktiviertem Workload Identity hinzu und migrieren Sie manuell Arbeitslasten zu diesem Pool. Dabei muss Workload Identity auch auf dem Cluster aktiviert sein.

gcloud container node-pools create NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --workload-metadata=GKE_METADATA

Wenn Workload Identity für einen Cluster aktiviert ist, können Sie es gezielt für einen bestimmten Knotenpool deaktivieren, indem Sie --workload-metadata=GCE_METADATA angeben. Weitere Informationen finden Sie unter Clustermetadaten schützen.

Option 2: Änderung des Knotenpools

Ändern Sie einen vorhandenen Knotenpool so, dass er den GKE-Metadatenserver verwendet. Für diese Aktualisierung muss im Cluster unbedingt Workload Identity aktiviert sein. Bei Änderung des Knotenpools wird Workload Identity für Arbeitslasten, die im Knotenpool bereitgestellt werden, sofort aktiviert. Diese Änderung verhindert, dass Arbeitslasten das Compute Engine-Dienstkonto verwenden. Sie muss vorsichtig eingeführt werden.

gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --workload-metadata=GKE_METADATA

Bei Google Cloud authentifizieren

In diesem Abschnitt wird erläutert, wie sich eine Anwendung mithilfe von Workload Identity bei Google Cloud authentifizieren kann. Weisen Sie der Anwendung ein Kubernetes-Dienstkonto zu und konfigurieren Sie das Kubernetes-Dienstkonto so, dass es als IAM-Dienstkonto fungiert.

  1. Konfigurieren Sie kubectl für die Kommunikation mit dem Cluster:

    gcloud container clusters get-credentials CLUSTER_NAME
    

    Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie im vorherigen Schritt erstellt haben.

  2. Wie die meisten anderen Ressourcen befinden sich auch Kubernetes-Dienstkonten in einem Namespace. Erstellen Sie den Namespace, der für das Kubernetes-Dienstkonto verwendet werden soll.

    kubectl create namespace K8S_NAMESPACE
    
  3. Erstellen Sie das Kubernetes-Dienstkonto für Ihre Anwendung:

    kubectl create serviceaccount KSA_NAME \
        --namespace K8S_NAMESPACE
    

    Dabei gilt:

    • KSA_NAME ist der Name des neuen Kubernetes-Dienstkontos.
    • K8S_NAMESPACE ist der Name des Kubernetes-Namespace, den Sie im vorherigen Schritt erstellt haben.
  4. Konfigurieren Sie Ihre Anwendung für die Verwendung des Kubernetes-Dienstkontos:

    spec:
      serviceAccountName: KSA_NAME
    
  5. Erstellen Sie ein IAM-Dienstkonto für Ihre Anwendung oder verwenden Sie stattdessen ein vorhandenes IAM-Dienstkonto. Sie können jedes IAM-Dienstkonto in jedem Projekt in Ihrer Organisation verwenden. Wenden Sie für Config Connector das Objekt IAMServiceAccount auf das ausgewählte Dienstkonto an.

    gcloud

    Führen Sie den folgenden Befehl aus, um ein neues IAM-Dienstkonto mit dem gcloud-Tool zu erstellen.

    gcloud iam service-accounts create GSA_NAME
    

    Ersetzen Sie GSA_NAME durch den Namen des neuen IAM-Dienstkontos.

    Config Connector

    Wenden Sie die folgende Konfigurationsdatei an, um ein neues oder vorhandenes IAM-Dienstkonto mit Config Connector zu verwenden.

    Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    metadata:
      name: [GSA_NAME]
    spec:
      displayName: [GSA_NAME]
    Um das Manifest bereitzustellen, laden Sie es als service-account.yaml auf Ihren Computer herunter.

    Verwenden Sie kubectl, um das Manifest anzuwenden:

    kubectl apply -f service-account.yaml
    

    Informationen zur Autorisierung von IAM-Dienstkonten für den Zugriff auf Google Cloud APIs finden Sie unter Details zu Dienstkonten.

  6. Achten Sie darauf, dass Ihr Google-Dienstkonto die erforderlichen IAM-Rollen hat. Mit dem folgenden Befehl können Sie zusätzliche Rollen zuweisen:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member "serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --role "ROLE_NAME"
    

    Dabei gilt:

    • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
    • GSA_NAME: der Name Ihres Google-Dienstkontos
    • ROLE_NAME: Die IAM-Rolle, die Ihrem Dienstkonto zugewiesen werden soll, z. B. roles/spanner.viewer.
  7. Erlauben Sie dem Kubernetes-Dienstkonto, die Identität des Google-Dienstkontos anzunehmen. Erstellen Sie dazu eine IAM-Richtlinienbindung zwischen den beiden. Durch diese Bindung kann das Kubernetes-Dienstkonto als IAM-Dienstkonto verwendet werden.

    gcloud

    gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]"
    

    Config Connector

    Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicy
    metadata:
      name: iampolicy-workload-identity-sample
    spec:
      resourceRef:
        apiVersion: iam.cnrm.cloud.google.com/v1beta1
        kind: IAMServiceAccount
        name: [GSA_NAME]
      bindings:
        - role: roles/iam.workloadIdentityUser
          members:
            - serviceAccount:[PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]]
    Um das Manifest bereitzustellen, laden Sie es als policy-binding.yaml auf Ihren Computer herunter. Ersetzen Sie GSA_NAME, PROJECT_ID, K8S_NAMESPACE und KSA_NAME durch die Werte für Ihre Umgebung. Führen Sie dann diesen Befehl aus:

    kubectl apply -f policy-binding.yaml
    
  8. Fügen Sie dem Kubernetes-Dienstkonto unter Verwendung der E-Mail-Adresse des IAM-Dienstkontos die Annotation iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID hinzu:

    kubectl

    kubectl annotate serviceaccount KSA_NAME \
        --namespace K8S_NAMESPACE \
        iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

    yaml

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      annotations:
        iam.gke.io/gcp-service-account:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
      name: KSA_NAME
      namespace: K8S_NAMESPACE
    
  9. Überprüfen Sie, ob die Dienstkonten ordnungsgemäß konfiguriert sind. Erstellen Sie dazu einen Pod mit dem Kubernetes-Dienstkonto, auf dem das betriebssystemspezifische Container-Image ausgeführt wird, und stellen Sie dann eine Verbindung für eine interaktive Sitzung her.

    Für Linux-Knoten

    1. Erstellen Sie einen Pod mit dem Kubernetes-Dienstkonto, der das Container-Image cloud-sdk ausführt:

      Speichern Sie die folgende Konfiguration als wi-test.yaml:

      apiVersion: v1
      kind: Pod
      metadata:
        name: workload-identity-test
        namespace: K8S_NAMESPACE
      spec:
        containers:
        - image: google/cloud-sdk:slim
          name: workload-identity-test
          command: ["sleep","infinity"]
        serviceAccountName: KSA_NAME
      

      Erstellen Sie einen Pod:

      kubectl apply -f wi-test.yaml
      

      Öffnen Sie eine interaktive Sitzung im Pod:

      kubectl exec -it workload-identity-test \
          --namespace K8S_NAMESPACE -- /bin/bash
      

      Das Image google/cloud-sdk enthält das gcloud-Befehlszeilentool, mit dem die Google Cloud APIs bequem genutzt werden können. Das Herunterladen des Images kann etwas dauern.

    2. Sie sind nun mit einer interaktiven Shell auf dem erstellten Pod verbunden. Führen Sie den folgenden Befehl im Pod aus:

      curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/
      

      Wenn die Dienstkonten ordnungsgemäß konfiguriert sind, wird die E-Mail-Adresse des IAM-Dienstkontos als aktive (und einzige) Identität aufgeführt. Dadurch wird ersichtlich, dass der Pod beim Aufrufen von Google Cloud APIs standardmäßig als Instanz des IAM-Dienstkontos fungiert.

    Windows Server-Knoten

    1. Erstellen Sie einen Pod mit dem Kubernetes-Dienstkonto, der das Container-Image servercore ausführt:

      apiVersion: v1
      kind: Pod
      metadata:
        name: workload-identity-test
        namespace: K8S_NAMESPACE
      spec:
        containers:
        - image: IMAGE_NAME
          name: workload-identity-test
          command: ["powershell.exe", "sleep", "3600"]
        serviceAccountName: KSA_NAME
        nodeSelector:
          kubernetes.io/os: windows
          cloud.google.com/gke-os-distribution: windows_ltsc
      

      Ersetzen Sie IMAGE_NAME durch einen der folgenden Container-Servercore-Image-Werte:

      Windows Server-Knoten-Image Container-servercore-Image
      WINDOWS_LTSC,
      WINDOWS_LTSC_CONTAINERD
      mcr.microsoft.com/windows/servercore:ltsc2019
      WINDOWS_SAC,
      WINDOWS_SAC_CONTAINERD
      Prüfen Sie die Versionszuordnung zwischen der GKE-Knotenversion und der Windows SAC-Version. Für Windows Server-Version 1909 geben Sie mcr.microsoft.com/windows/servercore:1909 an; ansonsten geben Sie mcr.microsoft.com/windows/servercore:20H2 an.

      Öffnen Sie eine interaktive Sitzung im Pod:

      kubectl exec -it workload-identity-test \
          --namespace K8S_NAMESPACE -- powershell
      
    2. Sie sind nun mit einer interaktiven Shell auf dem erstellten Pod verbunden. Führen Sie den folgenden Befehl im Pod aus:

      Invoke-WebRequest  -Headers @{"Metadata-Flavor"="Google"} -Uri  http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email  -UseBasicParsing
      

      Wenn die Dienstkonten ordnungsgemäß konfiguriert sind, wird die E-Mail-Adresse des IAM-Dienstkontos als aktive (und einzige) Identität aufgeführt. Dadurch wird ersichtlich, dass der Pod beim Aufrufen von Google Cloud APIs standardmäßig die Berechtigung des IAM-Dienstkontos verwendet.

Workload Identity über Ihren Code verwenden

Die Authentifizierung bei Google Cloud-Diensten über Ihren Code erfolgt genauso wie bei der Authentifizierung mit dem Compute Engine-Metadatenserver. Wenn Sie Workload Identity verwenden, werden Ihre an den Instanzmetadatenserver gerichteten Anfragen zum GKE-Metadatenserver geleitet. Vorhandener Code, der über den Metadatenserver der Instanz authentifiziert wird (z. B. Code, der die Google Cloud-Clientbibliotheken verwendet), sollte ohne Änderungen funktionieren.

Zugriff widerrufen

  1. Widerrufen Sie den Zugriff auf das IAM-Dienstkonto:

    gcloud

    gcloud iam service-accounts remove-iam-policy-binding GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]"
    

    Dabei gilt:

    • PROJECT_ID ist die Projekt-ID des GKE-Clusters.
    • K8S_NAMESPACE ist der Name des Kubernetes-Namespace, in dem sich Ihr Kubernetes-Dienstkonto befindet.
    • KSA_NAME ist der Name des Kubernetes-Dienstkontos, dessen Zugriff widerrufen wird.
    • GSA_NAME ist der Name des IAM-Dienstkontos.
    • GSA_PROJECT_ID ist die Projekt-ID des IAM-Dienstkontos.

    Config Connector

    Wenn Sie das Dienstkonto mithilfe von Config Connector erstellt haben, löschen Sie es mit kubectl:

    kubectl delete -f service-account.yaml
    

    Für diese Aktion sind iam.serviceAccounts.setIamPolicy-Berechtigungen für das Dienstkonto erforderlich.

    Es kann bis zu 30 Minuten dauern, bis die im Cache gespeicherten Tokens ablaufen. Mit diesem Befehl können Sie prüfen, ob die im Cache gespeicherten Tokens abgelaufen sind:

    gcloud auth list
    

    Die im Cache gespeicherten Tokens sind abgelaufen, wenn in der Ausgabe dieses Befehls GSA_NAME@PROJECT_ID.iam.gserviceaccount.com nicht mehr enthalten ist.

  2. Entfernen Sie die Annotation aus dem Kubernetes-Dienstkonto. Dieser Schritt ist optional, da der Zugriff von IAM widerrufen wurde.

    kubectl annotate serviceaccount KSA_NAME \
        --namespace K8S_NAMESPACE iam.gke.io/gcp-service-account-
    

Fehlerbehebung

Pod kann sich nicht bei Google Cloud authentifizieren

Wenn Ihre Anwendung sich nicht bei Google Cloud authentifizieren kann, prüfen Sie, ob diese Einstellungen ordnungsgemäß konfiguriert sind:

  1. Achten Sie darauf, dass die IAM Service Account Credentials API in dem Projekt aktiviert ist, das den GKE-Cluster enthält.

    IAM Credentials API aktivieren

  2. Workload Identity muss im Cluster aktiviert sein. Prüfen Sie dazu, ob der Workload Identity-Pool festgelegt ist:

    gcloud container clusters describe CLUSTER_NAME \
        --format="value(workloadIdentityConfig.workloadPool)"
    

    Wenn Sie noch keine Standardzone oder -region für gcloud angegeben haben, müssen Sie beim Ausführen dieses Befehls evtl. das Flag --region oder --zone angeben.

  3. Der GKE-Metadatenserver (GKE_METADATA) muss für den Knotenpool konfiguriert sein, in dem Ihre Anwendung ausgeführt wird:

    gcloud container node-pools describe NODEPOOL_NAME \
        --cluster=CLUSTER_NAME \
        --format="value(config.workloadMetadataConfig.mode)"
    
  4. Prüfen Sie, ob das Kubernetes-Dienstkonto richtig annotiert ist.

    kubectl describe serviceaccount \
        --namespace K8S_NAMESPACE KSA_NAME
    

    Die Annotation muss das folgende Format haben:

    iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    
  5. Prüfen Sie, ob das IAM-Dienstkonto richtig konfiguriert ist.

    gcloud iam service-accounts get-iam-policy \
        GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

    Prüfen Sie, ob eine Bindung im folgenden Format vorliegt:

    - members:
      - serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]
      role: roles/iam.workloadIdentityUser
    
  6. Wenn Sie eine Cluster-Netzwerkrichtlinie haben, muss ausgehender Traffic zu 127.0.0.1/32 an Port 988 für Cluster mit GKE-Versionen vor 1.21.0-gke.1000 oder zu 169.254.169.252/32 an Port 988 für Cluster mit GKE-Version 1.21.0-gke.1000 und höher zugelassen werden.

    kubectl describe networkpolicy NETWORK_POLICY_NAME
    

Zeitüberschreitungsfehler beim Starten des Pods

Der GKE-Metadatenserver benötigt einige Sekunden, damit er Anfragen auf einem neu erstellten Pod akzeptieren kann. Daher können Versuche, sich mithilfe von Workload Identity innerhalb der ersten Sekunden der Lebensdauer eines Pods zu authentifizieren, bei Anwendungen und Google Cloud-Clientbibliotheken, die nur mit einem kurzen Zeitlimit konfiguriert sind, fehlschlagen.

Wenn Zeitüberschreitungsfehler auftreten, können Sie den Anwendungscode ändern, um einige Sekunden zu warten, und es dann noch einmal versuchen. Alternativ können Sie einen initContainer bereitstellen, der wartet, bis der GKE-Metadatenserver bereit ist, bevor der Hauptcontainer des Pods ausgeführt wird.

Hier ist ein Pod mit einem Beispiel-initContainer:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-initcontainer
spec:
  serviceAccountName: KSA_NAME
  initContainers:
  - image:  gcr.io/google.com/cloudsdktool/cloud-sdk:326.0.0-alpine
    name: workload-identity-initcontainer
    command:
    - '/bin/bash'
    - '-c'
    - |
      curl -s -H 'Metadata-Flavor: Google' 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 30 > /dev/null || exit 1
  containers:
  - image: gcr.io/your-project/your-image
    name: your-main-application-container

Workload Identity schlägt aufgrund der Nichtverfügbarkeit der Steuerungsebene fehl

Der Metadatenserver kann die Workload Identity nicht zurückgeben, wenn die Steuerungsebene des Clusters nicht verfügbar ist. Aufrufe an den Metadatenserver geben den Statuscode 500 zurück.

Der Logeintrag kann im Log-Explorer etwa so aussehen:

dial tcp 35.232.136.58:443: connect: connection refused

Dies führt zu einer erwarteten Nichtverfügbarkeit von Workload Identity.

Die Steuerungsebene ist möglicherweise in zonalen Clustern bei Clusterwartungen wie dem Rotieren von IPs, dem Upgrade von Steuerungsebenen-VMs oder der Größenanpassung von Clustern oder Knotenpools nicht verfügbar. Weitere Informationen zur Verfügbarkeit der Steuerungsebene finden Sie unter Regionale oder zonale Steuerungsebene auswählen. Durch den Wechsel zum regionalen Cluster wird dieses Problem behoben.

Workload Identity schlägt fehl

Wenn der GKE-Metadatenserver blockiert wird, schlägt Workload Identity fehl.

Wenn Sie Istio verwenden, sollten Sie allen Arbeitslasten, die Workload Identity verwenden, die folgende Annotation auf Anwendungsebene hinzufügen:

"traffic.sidecar.istio.io/excludeOutboundIPRanges=169.254.169.254/32"

Alternativ können Sie dafür den Schlüssel Istio ConfigMap von global.proxy.excludeIPRanges ändern.

Workload Identity in einem Cluster deaktivieren

Sie können Workload Identity nur auf GKE Standard-Clustern deaktivieren.

  1. Deaktivieren Sie Workload Identity für jeden Knotenpool:

    gcloud container node-pools update NODEPOOL_NAME \
        --cluster=CLUSTER_NAME \
        --workload-metadata=GCE_METADATA
    

    Wiederholen Sie diesen Befehl für jeden Knotenpool im Cluster.

  2. Deaktivieren Sie Workload Identity im Cluster:

    gcloud container clusters update CLUSTER_NAME --disable-workload-identity
    

    Für diese Aktion sind container.clusters.update-Berechtigungen für den Cluster erforderlich.

Workload Identity in Ihrer Organisation deaktivieren

Im Hinblick auf die Sicherheit kann GKE mithilfe von Workload Identity Identitäten von Kubernetes-Dienstkonten durchsetzen, die authentifiziert und für Google Cloud-Ressourcen autorisiert werden können. Administratoren, die Maßnahmen ergriffen haben, um Arbeitslasten von Google Cloud-Ressourcen zu isolieren, indem sie z. B. die Erstellung von Dienstkonten deaktiviert oder die Erstellung von Dienstkontoschlüsseln deaktiviert haben, möchten möglicherweise auch Workload Identity für Ihre Organisation deaktivieren.

Hier finden Sie eine Anleitung zum Deaktivieren von Workload Identity für Ihre Organisation.

Nächste Schritte