Workload Identity verwenden

Auf dieser Seite wird erläutert, wie Ihre GKE-Anwendungen (Google Kubernetes Engine) Dienste nutzen, die von Google APIs bereitgestellt werden.

Übersicht

Für das Aufrufen von Google Cloud-Diensten aus Anwendungen in GKE wird Workload Identity empfohlen, da dieses Feature bessere Sicherheitsmerkmale bietet und leichter zu verwalten ist. Informationen zu alternativen Möglichkeiten für den Zugriff auf Google Cloud APIs über GKE finden Sie weiter unten im Abschnitt Alternativen.

Terminologie

In diesem Dokument wird zwischen Kubernetes-Dienstkonten und Google-Dienstkonten unterschieden. Kubernetes-Dienstkonten sind Kubernetes-Ressourcen, während Google-Dienstkonten für Google Cloud spezifisch sind. In anderen Dokumenten der Google Cloud-Dokumentation werden Google-Dienstkonten einfach als „Dienstkonten“ bezeichnet.

Konzepte

In GKE ausgeführte Anwendungen müssen für die Verwendung von Google Cloud APIs wie den Compute APIs, Storage und Database APIs oder Machine Learning APIs authentifiziert werden.

Mit Workload Identity können Sie ein Kubernetes-Dienstkonto konfigurieren, das als Google-Dienstkonto fungiert. Pods, die als Kubernetes-Dienstkonto ausgeführt werden, werden beim Zugriff auf Google Cloud APIs automatisch als Google-Dienstkonto authentifiziert. So können Sie jeder Anwendung in Ihrem Cluster separate, differenzierte Identitäten und Autorisierungen zuweisen.

Für eine sichere Zuordnung zwischen Kubernetes-Dienstkonten und Google-Dienstkonten führt Workload Identity das Konzept des Workload Identity-Pools eines Clusters ein. Damit kann Identity and Access Management (IAM) Anmeldedaten von Kubernetes-Dienstkonten vertrauen und sie verstehen.

Wenn Sie Workload Identity für Ihren GKE-Cluster aktivieren, wird der Workload Identity-Pool des Clusters auf PROJECT_ID.svc.id.goog festgesetzt. Dadurch kann IAM Kubernetes-Dienstkonten unter dem folgenden Mitgliedsnamen authentifizieren:

serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]

In diesem Mitgliedsnamen gilt:

  • PROJECT_ID.svc.id.goog ist der Workload Identity-Pool, der für den Cluster festgelegt ist.
  • KSA_NAME ist der Name des Kubernetes-Dienstkontos, von dem die Anfrage stammt.
  • K8S_NAMESPACE ist der Kubernetes-Namespace, in dem das Kubernetes-Dienstkonto definiert ist.

Es gibt nur einen festen Workload Identity-Pool pro Google Cloud-Projekt: PROJECT_ID.svc.id.goog. Dieser wird automatisch für Sie erstellt.

Gleiche Identität von Clustern

Alle Kubernetes-Dienstkonten mit gemeinsamem Namen, Namespace-Namen und Workload Identity-Pool werden zum selben Mitgliedsnamen aufgelöst und haben somit Zugriff auf Google Cloud-Ressourcen. Diese gemeinsame Identität ermöglicht es den Anwendungen, innerhalb eines Workload Identity-Pools Zugriff auf eine externe Ressource statt auf Cluster zu gewähren.

Das folgende Beispiel veranschaulicht diesen Aspekt. Die Cluster A, B und C sind in demselben Workload Identity-Pool angemeldet. Wenn Anwendungen im Namespace backend auf Google Cloud-Ressourcen zugreifen, werden ihre Identitäten einem gemeinsamen Google-Dienstkonto namens back zugeordnet, unabhängig davon, in welchem Cluster die Anwendung gehostet wird. Das Google-Dienstkonto back kann für eine beliebige Anzahl von Google Cloud APIs autorisiert werden, von Cloud Storage bis Cloud SQL.

Aufgrund der Identitätsgleichheit ist es wichtig, dass alle Cluster in einem Workload Identity-Pool als vertrauenswürdig eingestuft sind. Wenn im vorherigen Beispiel Cluster C zu einem separaten, nicht vertrauenswürdigen Team gehört, kann dieses auch einen backend-Namespace erstellen und auf Google Cloud APIs zugreifen, als wäre backend in Cluster A oder B.

Diagramm zur Identitätsgleichheit in einem Workload Identity-Arbeitspool
Identitätgleichheit beim Zugriff auf Google Cloud APIs mit Workload Identity

Um zu verhindern, dass Cluster Berechtigungen freigeben, müssen sich die Cluster in separaten Projekten befinden oder eindeutige Kubernetes-Namespace-Namen verwenden. Beispiel: Nutzer mit leicht zugänglichen "dev"-Clustern und gesperrten "prod"-Clustern sollten diese Cluster eventuell in separate Projekte aufteilen, um separate Workload Identity-Pools zu erhalten.

Beschränkungen

  • Derzeit gibt es nur einen festen Workload Identity-Pool pro Google Cloud-Projekt: PROJECT_ID.svc.id.goog. Dieser wird automatisch für Sie erstellt.

  • Derzeit wird Workload Identity nicht unterstützt, wenn eine Arbeitslast in Anthos-Clustern auf VMware ausgeführt wird.

  • Workload Identity macht die Verwendung der Metadatenverbergung überflüssig. Daher sind diese beiden Ansätze nicht kompatibel. Die vertraulichen Metadaten, die durch Metadatenverbergung geschützt werden, werden durch Workload Identity ebenfalls geschützt.

  • Wenn der GKE-Metadatenserver für einen Knotenpool aktiviert ist, können Pods nicht mehr auf den Compute Engine-Metadatenserver zugreifen. Stattdessen werden Anfragen dieser Pods an die Metadata APIs zum GKE-Metadatenserver geleitet. Die einzige Ausnahme sind Pods, die im Hostnetzwerk ausgeführt werden (siehe nächster Punkt).

  • Workload Identity kann nicht mit Pods verwendet werden, die im Hostnetzwerk ausgeführt werden. Anfragen von diesen Pods an die Metadata APIs werden zum Compute Engine-Metadatenserver geleitet.

  • Der GKE-Metadatenserver benötigt einige Sekunden, damit er Anfragen auf einem neu erstellten Pod akzeptieren kann. 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 [Fehlerbehebung]((#troubleshoot-timeout).

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

  • Workload Identity wird auf Windows-Knoten nicht unterstützt.

  • Workload Identity erfordert ein manuelles Einrichten von Cloud Run for Anthos in Google Cloud, um weiterhin Anfragemesswerte zur Verfügung zu stellen.

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

Vorbereitung

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

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

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

gcloud config verwenden

  • Legen Sie Ihre standardmäßige Projekt-ID fest:
    gcloud config set project PROJECT_ID
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Compute-Standardzone fest:
    gcloud config set compute/zone COMPUTE_ZONE
  • Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Compute-Standardregion fest:
    gcloud config set compute/region COMPUTE_REGION
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

Workload Identity in einem Cluster aktivieren

Sie können Workload Identity mit dem gcloud-Tool in einem neuen oder vorhandenen Cluster aktivieren.

  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.

    Für diese Aktion ist die Berechtigung container.clusters.create für das Projekt erforderlich.

  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.

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

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, um GKE_METADATA zu aktivieren. Für diese Aktualisierung muss auf dem Cluster unbedingt Workload Identity aktiviert sein. Für Arbeitslasten, die im Knotenpool bereitgestellt werden, wird Workload Identity 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

Für diese Aktion sind container.nodes.update-Berechtigungen für das Projekt erforderlich.

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 dazu der Anwendung ein Kubernetes-Dienstkonto zu und konfigurieren Sie es so, dass es als Google-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.

    Für diese Aktion ist die Berechtigung container.clusters.get für das Projekt erforderlich.

  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
    

    Für diese Aktion ist die RBAC-Berechtigung zum Erstellen eines Namespace im Cluster erforderlich.

  3. Erstellen Sie das Kubernetes-Dienstkonto für Ihre Anwendung:

    kubectl create serviceaccount --namespace K8S_NAMESPACE KSA_NAME
    

    Dabei gilt:

    • K8S_NAMESPACE ist der Name des Kubernetes-Namespace, den Sie im vorherigen Schritt erstellt haben.
    • KSA_NAME ist der Name, den Sie für das Kubernetes-Dienstkonto verwenden möchten.

    Für diese Aktion ist die RBAC-Berechtigung zum Erstellen von Dienstkonten im Namespace erforderlich.

    Alternativ können Sie den Standard-Namespace oder das Kubernetes-Standarddienstkonto in einem beliebigen Namespace verwenden.

  4. Erstellen Sie ein Google-Dienstkonto für Ihre Anwendung. Wenn Sie bereits ein Dienstkonto haben, können Sie dieses verwenden, statt ein neues zu erstellen. Das Dienstkonto muss sich nicht im selben Projekt wie Ihr Cluster befinden. Sie können jedes Google-Dienstkonto in Ihrer Organisation verwenden.

    gcloud

    Ersetzen Sie GSA_NAME durch den Namen, den Sie für das Dienstkonto ausgewählt haben.

    gcloud iam service-accounts create GSA_NAME
    

    Config Connector

    Wenn Sie Config Connector bereits auf einem Cluster installiert haben, können Sie bei aktiviertem Workload Identity mithilfe einer Config Connector-Konfiguration einen neuen GKE-Cluster erstellen.

    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. Ersetzen Sie GSA_NAME durch den Namen, den Sie für das Dienstkonto ausgewählt haben. Verwenden Sie dann kubectl, um das Manifest anzuwenden.

    kubectl apply -f service-account.yaml

    Für diese Aktion ist die Berechtigung iam.serviceAccounts.create für das Projekt erforderlich.

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

  5. 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 Google-Dienstkonto verwendet werden.

    gcloud

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

    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

    Für diese Aktion ist die Berechtigung iam.serviceAccounts.setIamPolicy für das Projekt erforderlich.

  6. Fügen Sie dem Kubernetes-Dienstkonto unter Verwendung der E-Mail-Adresse des Google-Dienstkontos die Annotation iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID hinzu:

    kubectl

    kubectl annotate serviceaccount \
      --namespace K8S_NAMESPACE \
      KSA_NAME \
      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
    

    Für diese Aktion sind RBAC-Berechtigungen zum Bearbeiten für das Kubernetes-Dienstkonto erforderlich.

  7. Prüfen Sie, ob die Dienstkonten ordnungsgemäß konfiguriert sind. Erstellen Sie dazu einen Pod mit dem Kubernetes-Dienstkonto, der das Container-Image cloud-sdk ausführt, und stellen Sie in einer interaktiven Sitzung eine Verbindung zum Pod her.

    kubectl

    kubectl run -it \
      --image google/cloud-sdk:slim \
      --serviceaccount KSA_NAME \
      --namespace K8S_NAMESPACE \
      workload-identity-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
    

    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.

    Für diese Aktion ist eine Berechtigung zum Erstellen einer RBAC für Pods im Namespace erforderlich.

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

    gcloud auth list
    

    Wenn die Dienstkonten ordnungsgemäß konfiguriert sind, wird die E-Mail-Adresse des Google-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 Google-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.

GKE-Metadatenserver

Der GKE-Metadatenserver ist ein neuer Metadatenserver, der für die Verwendung mit Kubernetes entwickelt wurde. Er wird als DaemonSet mit genau einem Pod auf jedem Clusterknoten ausgeführt. Der Metadatenserver fängt HTTP-Anfragen an http://metadata.google.internal (169.254.169.254:80) ab, einschließlich Anfragen wie GET /computeMetadata/v1/instance/service-accounts/default/token, um ein Token für das Google-Dienstkonto abzurufen, als das der Pod gemäß der Konfiguration fungiert. Der Traffic zum Metadatenserver verlässt nie die VM-Instanz, die den Pod hostet.

Der GKE-Metadatenserver implementiert nur einen Teil der Compute Engine-Metadatenserver-Endpunkte, die für Kubernetes-Arbeitslasten relevant und sicher sind:

  • /computeMetadata/v1/instance/attributes/cluster-location
  • /computeMetadata/v1/instance/attributes/cluster-name
  • /computeMetadata/v1/instance/attributes/cluster-uid
  • /computeMetadata/v1/instance/hostname
  • /computeMetadata/v1/instance/id
  • /computeMetadata/v1/project/numeric-project-id
  • /computeMetadata/v1/project/project-id
  • /computeMetadata/v1/instance/service-accounts
  • /computeMetadata/v1/instance/service-accounts/default
  • /computeMetadata/v1/instance/service-accounts/default/aliases
  • /computeMetadata/v1/instance/service-accounts/default/email
  • /computeMetadata/v1/instance/service-accounts/default/identity
  • /computeMetadata/v1/instance/service-accounts/default/identity?audience=audience
  • /computeMetadata/v1/instance/service-accounts/default/scopes
  • /computeMetadata/v1/instance/service-accounts/default/token
  • /computeMetadata/v1/instance/service-accounts/default/token?scopes=comma-separated-list-of-scopes

Zugriff widerrufen

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

    gcloud

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

    Dabei gilt:

    • PROJECT_ID ist der Projekt-ID-Container für den GKE-Cluster.
    • 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 Google-Dienstkontos.
    • GSA_PROJECT_ID ist die ID des Projekts, in dem das Google-Dienstkonto enthalten ist.

    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 \
      --namespace K8S_NAMESPACE \
      KSA_NAME \
      iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

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)"
    
  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 Google-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 an 127.0.0.1/32 über Port 988 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 Authentifizierungsversuche mit Workload Identity innerhalb der ersten paar Sekunden eines Pods bei Anwendungen und Google Cloud-Client-Bibliotheken, die mit einem kurzen Timeout 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://169.254.169.254/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 in einem Cluster 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 haben 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.

Alternativen zu Workload Identity

Für den Zugriff auf Cloud APIs über GKE gibt es zwei alternative Methoden. Mit dem Release von Workload Identity empfehlen wir diese Ansätze aufgrund der erforderlichen Kompromisse nicht mehr.

  1. Dienstkontoschlüssel exportieren und als Kubernetes-Secrets speichern. Google-Dienstkontoschlüssel laufen nach zehn Jahren ab und werden manuell rotiert. Der Export von Dienstkontoschlüsseln kann den Umfang einer Sicherheitsverletzung vergrößern, wenn diese nicht erkannt wird.

  2. Das Compute Engine-Dienstkonto Ihrer Knoten verwenden. Sie können Knotenpools als ein beliebiges IAM-Dienstkonto in Ihrem Projekt ausführen. Wenn Sie beim Erstellen des Knotenpools kein Dienstkonto angeben, verwendet GKE das Compute Engine-Standarddienstkonto des Projekts. Das Compute Engine-Dienstkonto wird von allen auf diesem Knoten bereitgestellten Arbeitslasten gemeinsam genutzt. Dies kann dazu führen, dass zu viele Berechtigungen bereitgestellt werden.

Weitere Informationen