Workload Identity-Föderation mit Kubernetes konfigurieren

In diesem Leitfaden wird beschrieben, wie Sie mit Workload Identity-Föderation Arbeitslasten, die in Azure Kubernetes Service (AKS) oder in einem selbst gehosteten Kubernetes-Cluster ausgeführt werden, bei Google Cloud authentifizieren können.

Mit Kubernetes können Sie einen Cluster so konfigurieren, dass Arbeitslasten Kubernetes-Dienstkonto-Tokens aus einem projizierten Volume abrufen können. Wenn Sie die Workload Identity-Föderation einrichten, können Arbeitslasten diese Kubernetes-Dienstkonto-Tokens zur Authentifizierung bei Google Cloud verwenden.

Wenn Sie GKE verwenden, verwenden Sie anstelle von Workload Identity-Föderation Workload Identity Federation for GKE.

Hinweise

Prüfen Sie vor der Konfiguration der Workload Identity-Föderation, ob Ihr Kubernetes-Cluster die folgenden Kriterien erfüllt:

Identitätsföderation von Arbeitslasten konfigurieren

Sie müssen diese Schritte nur einmal für jeden Kubernetes-Cluster ausführen. Sie können dann denselben Workload Identity-Pool und -Anbieter für mehrere Arbeitslasten und mehrere Google Cloud-Projekte verwenden.

So konfigurieren Sie die Workload Identity-Föderation:

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

Wir empfehlen, ein dediziertes Projekt zur Verwaltung von Workload Identity-Pools und -Anbietern.

2. Make sure that billing is enabled for your Google Cloud project.

Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs.

Enable the APIs

Attributzuordnung und -bedingung definieren

Tokens für Kubernetes-Dienstkonten enthalten mehrere Anforderungen, darunter:

• sub: enthält den Namespace und den Namen des Dienstkontos, z. B. system:serviceaccount:NAMESPACE:KSA_NAME, wobei NAMESPACE der Namespace des Dienstkontos und KSA_NAME der Name des Dienstkontos ist.
• "kubernetes.io".namespace: enthält den Namespace des ServiceAccount.
• "kubernetes.io".serviceaccount.name: enthält den Namen des ServiceAccount.
• "kubernetes.io".pod.name: enthält den Namen des Pods.

Wenn Sie sub als Betreffkennung (google.subject) in Google Cloud nutzen möchten, verwenden Sie die folgende Zuordnung:

google.subject=assertion.sub

Optional können Sie zusätzliche Attribute zuordnen. Sie können dann auf diese Attribute verweisen, wenn Sie Zugriff auf Ressourcen gewähren. Beispiel:

google.subject=assertion.sub,
attribute.namespace=assertion['kubernetes.io']['namespace'],
attribute.service_account_name=assertion['kubernetes.io']['serviceaccount']['name'],
attribute.pod=assertion['kubernetes.io']['pod']['name']

Definieren Sie optional eine Attributbedingung. Attributbedingungen sind CEL-Ausdrücke, die Assertion-Attribute und Zielattribute prüfen können. Wenn die Attributbedingung bei bestimmten Anmeldedaten als true ausgewertet wird, werden die Anmeldedaten akzeptiert. Andernfalls werden die Anmeldedaten abgelehnt.

Mit einer Attributbedingung können Sie einschränken, welche Kubernetes-Dienstkonten die Workload Identity-Föderation verwenden können, um kurzlebige Google Cloud-Tokens abzurufen. Die folgende Bedingung beschränkt beispielsweise den Zugriff auf Kubernetes-Dienstkonten aus den Namespaces backend und monitoring:

assertion['kubernetes.io']['namespace'] in ['backend', 'monitoring']

Workload Identity-Pool und -Anbieter erstellen

So erstellen Sie einen Workload Identity-Pool und -Anbieter:

Zugriff auf eine Kubernetes-Arbeitslast gewähren

In diesem Abschnitt wird beschrieben, wie Sie eine Kubernetes-Arbeitslast so konfigurieren, dass sie entweder über den direkten Ressourcenzugriff der Workload Identity-Föderation oder die Identitätsübernahme eines Dienstkontos auf Google Cloud APIs zugreift.

Sie müssen diese Schritte einmal für jede Kubernetes-Arbeitslast ausführen, die Zugriff auf Google Cloud benötigt.

Wir empfehlen die Verwendung der Workload Identity-Föderation. Bei der Verwendung der Identitätsföderation können jedoch bestimmte API-Methoden eingeschränkt sein. Eine Liste der Einschränkungen finden Sie unter Identity-Föderation: Produkte und Einschränkungen.

Wenn die Methoden, die Ihre Arbeitslast verwendet, solche Einschränkungen haben, können Sie stattdessen die IAM-Identitätsübernahme verwenden.

Workload Identity-Föderation verwenden, um direkten Ressourcenzugriff zu gewähren

In diesem Abschnitt verwenden Sie die Workload Identity-Föderation, um einem Kubernetes-Dienstkonto eine IAM-Rolle zuzuweisen, damit es direkt auf Google Cloud-Ressourcen zugreifen kann.

So erstellen Sie ein Kubernetes-Dienstkonto und gewähren ihm eine Rolle:

1. Erstellen Sie ein Kubernetes-ServiceAccount:

   kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
   

   Ersetzen Sie Folgendes:

   • KSA_NAME: Ein Name für das ServiceAccount.
   • NAMESPACE: Der Namespace, in dem das ServiceAccount erstellt werden soll.

2. Gewähren Sie dem Kubernetes-Dienstkonto IAM-Zugriff auf eine Google Cloud-Ressource.

   Gemäß dem Prinzip der geringsten Berechtigung empfehlen wir, nur Rollen zu gewähren, die für die Ressourcen spezifisch sind, auf die Ihre Anwendung zugreifen muss.

   Im folgenden Beispiel wird dem von Ihnen erstellten ServiceAccount die Rolle Kubernetes Engine-Clusterbetrachter (roles/container.clusterViewer) zugewiesen. Der Befehl verwendet das Thema, das Sie zuvor in diesem Dokument zugeordnet haben.

   gcloud projects add-iam-policy-binding projects/PROJECT_ID \
       --role=roles/container.clusterViewer \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MAPPED_SUBJECT \
       --condition=None
   

   Ersetzen Sie Folgendes:

   • PROJECT_NUMBER: die numerische Google Cloud-Projektnummer, die mit Ihrer Projekt-ID verknüpft ist.

   • POOL_ID: die ID des Workload Identity-Pools.

   • MAPPED_SUBJECT: das Kubernetes-Dienstkonto aus dem Anspruch in Ihrem ID-Token, das Sie google.subject zugeordnet haben. Wenn du beispielsweise google.subject=assertions.sub zugeordnet hast und dein ID-Token "sub": "system:serviceaccount:default:my-kubernetes-serviceaccount" enthält, ist MAPPED_SUBJECT system:serviceaccount:default:my-kubernetes-serviceaccount.

   Sie können jeder Google Cloud-Ressource, die IAM-Zulassungsrichtlinien unterstützt, Rollen zuweisen. Die Syntax der Hauptkonto-ID hängt von der Kubernetes-Ressource ab. Eine Liste der unterstützten IDs finden Sie unter Hauptkonto-IDs für Workload Identity Federation for GKE.

Sie können jetzt eine Arbeitslast bereitstellen, die über das Kubernetes-Dienstkonto auf die Google Cloud-Ressourcen zugreift, für die Sie Zugriff gewährt haben.

Alternative: Zugriff mit Identitätsübernahme des IAM-Dienstkontos gewähren

So konfigurieren Sie Ihr Kubernetes-Dienstkonto für die Identitätsübernahme durch IAM-Dienstkonten:

1. Erstellen Sie ein Kubernetes-Dienstkonto, falls noch nicht geschehen:

   kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
   

   Ersetzen Sie Folgendes:

   • KSA_NAME: ein Name für das ServiceAccount
   • NAMESPACE: der Namespace, in dem das ServiceAccount erstellt werden soll

2. Erstellen Sie ein IAM-Dienstkonto, das die Arbeitslast darstellt.

   Das Dienstkonto muss sich nicht im selben Projekt wie der Workload Identity-Pool befinden. Sie müssen sich aber auf das Projekt beziehen, das das Dienstkonto enthält.

   gcloud iam service-accounts create IAM_SA_NAME \
       --project=IAM_SA_PROJECT_ID
   

   Ersetzen Sie Folgendes:

   • IAM_SA_NAME: der Name des Dienstkontos
   • IAM_SA_PROJECT_ID: die Projekt-ID des Dienstkontos

3. Gewähren Sie Ihrem IAM-Dienstkonto Zugriff auf die Google Cloud-Ressourcen, auf die die Kubernetes-Arbeitslast zugreifen soll.

   gcloud projects add-iam-policy-binding IAM_SA_PROJECT_ID \
       --member="serviceAccount:IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com" \
       --role="ROLE"
   

   Ersetzen Sie Folgendes:

   • IAM_SA_PROJECT_ID: die ID des Projekts, in dem Sie das Dienstkonto erstellt haben
   • IAM_SA_NAME: der Name des Dienstkontos
   • ROLE: mit dem Namen der Rolle, z. B. roles/container.clusterViewer

4. Gewähren Sie dem Kubernetes-ServiceAccount Zugriff, um die Identität des IAM-Dienstkontos zu übernehmen:

   gcloud iam service-accounts add-iam-policy-binding \
     IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \
       --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MAPPED_SUBJECT" \
       --role=roles/iam.workloadIdentityUser
   
   

   Ersetzen Sie Folgendes:

   • IAM_SA_NAME: der Name des Dienstkontos
   • PROJECT_ID: die ID des Projekts, in dem Sie Kubernetes ausführen
   • IAM_SA_PROJECT_NUMBER: die Projektnummer des Projekts, in dem Sie das Dienstkonto erstellt haben
   • POOL_ID: die ID des Workload Identity-Pools.
   • MAPPED_SUBJECT: das Kubernetes-Dienstkonto aus dem Anspruch in Ihrem ID-Token, das Sie google.subject zugeordnet haben. Wenn du beispielsweise google.subject=assertions.sub zugeordnet hast und dein ID-Token "sub": "system:serviceaccount:default:my-kubernetes-serviceaccount" enthält, ist MAPPED_SUBJECT system:serviceaccount:default:my-kubernetes-serviceaccount.

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

Sie können jetzt eine Arbeitslast bereitstellen, die das Kubernetes-Dienstkonto und das IAM-Dienstkonto verwendet, um auf die Google Cloud-Ressourcen zuzugreifen, für die Sie Zugriff gewährt haben.

Kubernetes-Arbeitslast bereitstellen

So stellen Sie eine Kubernetes-Arbeitslast bereit, die auf Google Cloud-Ressourcen zugreifen kann:

1. Erstellen Sie eine Konfigurationsdatei für Anmeldedaten:

   gcloud iam workload-identity-pools create-cred-config \
       projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
       --service-account=SERVICE_ACCOUNT_EMAIL \
       --credential-source-file=/var/run/service-account/token \
       --credential-source-type=text \
       --output-file=credential-configuration.json

   Ersetzen Sie Folgendes:

   • PROJECT_NUMBER: die Projektnummer des Projekts, das den Workload Identity-Pool enthält
   • POOL_ID: die ID des Workload Identity-Pools
   • WORKLOAD_PROVIDER_ID: die ID des Workload Identity-Poolanbieters
   • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos, wenn Sie Ihr Kubernetes-Dienstkonto so konfiguriert haben, dass es die Identitätsdiebstahl-Funktion für IAM-Dienstkonten verwendet. Lassen Sie dieses Flag weg, wenn Sie Ihr Kubernetes-Dienstkonto für den direkten Ressourcenzugriff konfiguriert haben.

   Mit der Konfigurationsdatei für Anmeldedaten können die Cloud-Clientbibliotheken, die gcloud CLI und Terraform Folgendes ermitteln:

   • Wo externe Anmeldedaten abgerufen werden
   • Welcher Workload Identity-Pool und -Anbieter verwendet werden
   • Welches Dienstkonto übernommen wird

2. Importieren Sie die Konfigurationsdatei für Anmeldedaten als ConfigMap.

   kubectl create configmap CONFIGMAP_NAME \
     --from-file credential-configuration.json \
     --namespace NAMESPACE
   

   Ersetzen Sie Folgendes:

   • CONFIGMAP_NAME: der Name der ConfigMap.
   • NAMESPACE: der Namespace, in dem die ConfigMap erstellt werden soll.

3. Stellen Sie eine Arbeitslast bereit und lassen Sie sie das Kubernetes-Dienstkonto und ConfigMap verwenden.

   Erstellen Sie ein Manifest und konfigurieren Sie es so:

   • Stellen Sie ein projiziertes Token-Volume bereit, damit die Arbeitslast ein Kubernetes-Dienstkonto-Token aus einer lokalen Datei abrufen kann. Konfigurieren Sie das Volume so, dass das Token des Kubernetes-Dienstkontos die Zielgruppe verwendet, die vom Workload Identity-Poolanbieter erwartet wird.
   • Stellen Sie die ConfigMap bereit, die die Konfigurationsdatei für Anmeldedaten enthält, damit die Arbeitslast auf die erforderliche Konfiguration für die Verwendung der Workload Identity-Föderation zugreifen kann.
   • Fügen Sie eine Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS hinzu, die den Pfad der Konfigurationsdatei für Anmeldedaten enthält, damit Arbeitslasten die Datei finden können.

   Das folgende Beispiel zeigt das Kubernetes-Dienstkonto und die ConfigMap, damit sich die Google Cloud CLI bei Google Cloud authentifizieren kann:

   apiVersion: v1
   kind: Pod
   metadata:
     name: example
     namespace: NAMESPACE
   spec:
     containers:
     - name: example
       image: google/cloud-sdk:alpine
       command: ["/bin/sh", "-c", "gcloud auth login --cred-file $GOOGLE_APPLICATION_CREDENTIALS && gcloud auth list && sleep 600"]
       volumeMounts:
       - name: token
         mountPath: "/var/run/service-account"
         readOnly: true
       - name: workload-identity-credential-configuration
         mountPath: "/etc/workload-identity"
         readOnly: true
       env:
       - name: GOOGLE_APPLICATION_CREDENTIALS
         value: "/etc/workload-identity/credential-configuration.json"
   
     serviceAccountName: KSA_NAME
     volumes:
     - name: token
       projected:
         sources:
         - serviceAccountToken:
             audience: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID
             expirationSeconds: 3600
             path: token
     - name: workload-identity-credential-configuration
       configMap:
         name: CONFIGMAP_NAME

   Sie können genauso vorgehen, damit Tools und Arbeitslasten, die eine der folgenden Clientbibliotheken verwenden, Anmeldedaten automatisch finden:

   C++

   Die Google Cloud-Clientbibliotheken für C++ unterstützen die Mitarbeiteridentitätsföderation seit Version v2.6.0. Wenn Sie die Mitarbeiteridentitätsföderation verwenden möchten, müssen Sie die Clientbibliotheken mit Version 1.36.0 oder höher von gRPC erstellen.

   Go

   Clientbibliotheken für Go unterstützen die Identitätsföderation von Arbeitslasten, wenn sie Version 0.0.0-2021218202405-ba52d332ba99 oder höher des Moduls golang.org/x/oauth2 verwenden.

   Führen Sie die folgenden Befehle aus, um zu überprüfen, welche Version dieses Moduls in Ihrer Clientbibliothek verwendet wird:

   cd $GOPATH/src/cloud.google.com/go
   go list -m golang.org/x/oauth2
   

   Java

   Clientbibliotheken für Java unterstützen die Identitätsföderation von Arbeitslasten, wenn sie Version 0.24.0 oder höher des com.google.auth:google-auth-library-oauth2-http-Artefakts verwenden.

   Führen Sie den folgenden Maven-Befehl in Ihrem Anwendungsverzeichnis aus, um zu überprüfen, welche Version dieses Artefakts Ihre Clientbibliothek verwendet:

   mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http
   

   Node.js

   Clientbibliotheken für Node.js unterstützen die Workload Identity-Föderation, wenn sie Version 7.0.2 oder höher des google-auth-library-Pakets verwenden.

   Führen Sie den folgenden Befehl in Ihrem Anwendungsverzeichnis aus, um zu überprüfen, welche Version dieses Pakets verwendet wird:

   npm list google-auth-library
   

   Wenn Sie ein GoogleAuth-Objekt erstellen, können Sie eine Projekt-ID angeben oder GoogleAuth erlauben, automatisch nach der Projekt-ID zu suchen. Damit automatisch nach der Projekt-ID gesucht werden kann, muss das Dienstkonto in der Konfigurationsdatei in Ihrem Projekt die Rolle „Sucher“ (roles/browser) oder eine Rolle mit entsprechenden Berechtigungen haben. Weitere Informationen finden Sie unter README für das Paket google-auth-library.

   Python

   Clientbibliotheken für Python unterstützen die Identitätsföderation von Arbeitslasten, wenn sie Version 1.27.0 oder höher des google-auth-Pakets verwenden.

   Führen Sie den folgenden Befehl in der Umgebung aus, in der das Paket installiert ist, um zu ermitteln, welche Version dieses Pakets verwendet wird:

   pip show google-auth
   

   Wenn Sie eine Projekt-ID für den Authentifizierungsclient angeben, können Sie die Umgebungsvariable GOOGLE_CLOUD_PROJECT festlegen oder Sie gestatten dem Client, automatisch nach der Projekt-ID zu suchen. Damit automatisch nach der Projekt-ID gesucht werden kann, muss das Dienstkonto in der Konfigurationsdatei in Ihrem Projekt die Rolle „Sucher“ (roles/browser) oder eine Rolle mit entsprechenden Berechtigungen haben. Weitere Informationen finden Sie im Nutzerhandbuch für das Paket google-auth.

   gcloud

   Verwenden Sie zum Authentifizieren der Workload Identity-Föderation den Befehl gcloud auth login:

   gcloud auth login --cred-file=FILEPATH.json
   

   Ersetzen Sie FILEPATH durch den Pfad zur Konfigurationsdatei für Anmeldedaten.

   Unterstützung für die Workload Identity-Föderation in der gcloud CLI ist in Version 363.0.0 und höher des gcloud CLI verfügbar.

   Terraform

   Der Google Cloud-Anbieter unterstützt die Workload Identity-Föderation, wenn Sie Version 3.61.0 oder höher verwenden:

   terraform {
     required_providers {
       google = {
         source  = "hashicorp/google"
         version = "~> 3.61.0"
       }
     }
   }
   

   bq

   Verwenden Sie für die Authentifizierung mithilfe der Workload Identity-Föderation den Befehl gcloud auth login:

   gcloud auth login --cred-file=FILEPATH.json
   

   Ersetzen Sie FILEPATH durch den Pfad zur Konfigurationsdatei für Anmeldedaten.

   Unterstützung für Workload Identity-Föderation in bq ist in Version 390.0.0 und späteren Versionen der gcloud CLI verfügbar.

4. Optional können Sie prüfen, ob die Authentifizierung ordnungsgemäß funktioniert, indem Sie den folgenden Befehl ausführen:

   kubectl exec example --namespace NAMESPACE -- gcloud auth print-access-token

Nächste Schritte

• Weitere Informationen zur Workload Identity-Föderation
• Best Practices für die Verwendung der Workload Identity-Föderation
• Workload Identity-Pools und -Anbieter verwalten