Über Workloads der Flotte bei APIs und Diensten authentifizieren

Auf dieser Seite erfahren Sie, wie Sie Ihre Anwendungen so konfigurieren, dass sie sich mithilfe der Workload Identity Federation der Flotte bei Google Cloud APIs wie der Compute Engine API oder der AI Platform API authentifizieren.

Was ist die Identitätsföderation von Arbeitslasten für Flotten?

Mit der Workload Identity-Föderation können sich die Arbeitslasten in Ihren Clustern bei Google Cloud authentifizieren, ohne dass Sie Anmeldedaten herunterladen, manuell rotieren und im Allgemeinen verwalten müssen. Stattdessen werden die Arbeitslasten mithilfe der von Google Cloud generierten kurzlebigen Tokens authentifiziert.

Die Identitätsföderation von Arbeitslasten für GKE bietet einen projektweiten Pool mit Arbeitslastenidentitäten, aus dem Anwendungen, die in GKE-Clustern ausgeführt werden, Identitäten erhalten. Die Identitätsföderation von Arbeitslasten für Flotten erweitert die Identitätsföderation von Arbeitslasten für GKE auf alle Cluster von Flottenmitgliedern, unabhängig davon, ob sich die Cluster in verschiedenen Projekten oder außerhalb von Google Cloud befinden. Registrierte Cluster, für die die Workload Identity-Föderation für die Flottenmitgliedschaft aktiviert ist, erhalten Identitäten über einen flächendeckenden Workload Identity-Pool. So können Sie die Authentifizierung bei Google Cloud APIs und anderen Diensten in Ihrer gesamten Flotte und sogar in mehreren Projekten konfigurieren.

Flotten Workload Identity-Föderation kann auch von dem Connect-Agent auf einigen Clustertypen verwendet werden, um sich im Rahmen der Flotte-Mitgliedschaft in Google Cloud zu authentifizieren. Außerdem ist es erforderlich, um einige projektübergreifende GKE Enterprise-Features wie Cloud Service Mesh zu nutzen.

Pools der Workload Identity-Föderation und Identitätsgleichheit

Mit der Workload Identity-Föderation für Flotten erhält jede Anwendung in Ihrer Flotte eine eindeutige föderierte Identität, mit der sie sich bei Google Cloud und anderen von Ihnen entwickelten Diensten authentifizieren kann. Anwendungen erhalten eine Hauptkonto-ID, die von IAM erkannt werden kann. Diese Kennzeichnung verwendet die folgende Syntax:

PREFIX://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_PROJECT_ID.svc.id.goog/SELECTOR

Diese Syntax hat die folgenden Felder:

  • PREFIX: die IAM-principal oder principalSet, je nach ausgewählter Ressource.
  • FLEET_PROJECT_ID.svc.id.goog: den Workload Identity-Pool für Ihre Flotte. Jede Flotte hat einen einzelnen festen Workload Identity-Pool, der für Sie erstellt wird.
  • FLEET_PROJECT_NUMBER: Die Projektnummer des Flotten-Hostprojekts
  • SELECTOR: die Ressourcenauswahl. Eine Liste der unterstützten Auswählten finden Sie unter Unterstützte Hauptkonto-IDs.

Die gesamte Flotte teilt sich einen Flotten-Workload Identity-Pool. So können Sie Anwendungen überall in der Flotte, einschließlich in anderen Projekten oder Clouds, Zugriff auf dieselben Ressourcen gewähren, ohne diesen Zugriff für jeden Cluster verwalten zu müssen. Wie andere für eine Flotte aktivierte Funktionen basiert die Arbeitslastidentitätsfederation für Flotten auf dem Prinzip der Gleichheit. Dabei werden Kubernetes-Objekte mit demselben Namen und Namespace in verschiedenen Clustern gleich behandelt.

Wenn Sie beispielsweise eine Anwendung mit einem Back-End haben, das in mehreren Clustern in derselben Flotte bereitgestellt wird und sich bei einer Google Cloud API authentifizieren muss, können Sie die Anwendung so konfigurieren, dass alle Arbeitslasten im Namespace backend auf diese API zugreifen können. Weitere Informationen zur Verwendung der Gleichheit, einschließlich der Identitätsgleichheit, finden Sie unter Funktionsweise von Flotten.

Nachdem Sie die Identitätsföderation von Arbeitslasten für die Flotte aktiviert haben, können Sie in IAM-Zulassungsrichtlinien auf Hauptkonten in Ihrer Flotte verweisen, indem Sie die entsprechende Hauptkonto-ID angeben. Sie können beispielsweise in Ihrer Zulassungsrichtlinie auf ein bestimmtes Dienstkonto in einem bestimmten Kubernetes-Namespace verweisen. Alle Anwendungen, die dieses Dienstkonto verwenden, können dann auf die Google Cloud-Ressource zugreifen, auf die sich die IAM-Zulassungsrichtlinie bezieht.

Anmeldedatenfluss

So können Sie Anwendungen in einem bestimmten Namespace mithilfe der Workload Identity-Föderation der Flotte authentifizieren:

  1. Stellen Sie in diesem Namespace eine ConfigMap mit den folgenden Informationen bereit:

    • den Workload Identity-Pool und den Identitätsanbieter für Ihren Cluster.
    • Der Pfad in jedem Pod, auf dem Kubernetes ein Dienstkonto-Token bereitstellt. Dieses Token ist ein signiertes JSON Web Token (JWT).

    Diese ConfigMap dient als Datei mit den Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) für Arbeitslasten.

  2. Erstellen Sie eine IAM-Zulassungsrichtlinie, die der Hauptkonto-ID des Hauptkontos in Ihren Clustern Zugriff auf bestimmte Google Cloud-Ressourcen gewährt, z. B. einem Dienstkonto im Namespace.

  3. Achten Sie darauf, dass Ihre Arbeitslast im Namespace die folgenden Konfigurationen in der Pod-Spezifikation hat:

    • Die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS ist auf den Bereitstellungspfad der ConfigMap im Pod festgelegt.
    • Ein projiziertes Volume, das das Dienstkonto-Token und das von Ihnen erstellte ConfigMap enthält, das unter demselben Pfad bereitgestellt wird, den Sie in der Umgebungsvariablen GOOGLE_APPLICATION_CREDENTIALS angeben.
    • Eine Volume-Bereitstellung im Container, die auf das projizierte Volume verweist.

Wenn die Arbeitslast einen Google Cloud API-Aufruf ausführt, geschieht Folgendes:

  1. Die Google Cloud-Authentifizierungsbibliotheken verwenden Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) für die Suche nach Anmeldedaten. ADC prüft den Pfad, den Sie in der Umgebungsvariablen GOOGLE_APPLICATION_CREDENTIALS angegeben haben, um nach einem Authentifizierungstoken zu suchen.
  2. Die ADC-Authentifizierungsbibliothek verwendet die Daten in der ConfigMap, um das Dienstkonto-JWT, das Sie auf dem Pod bereitgestellt haben, gegen ein kurzlebiges föderiertes Token von Security Token Service auszutauschen, das auf die Haupt-ID der Arbeitslast verweist.
  3. ADC fügt das föderierte Token in die API-Anfrage ein.
  4. Die IAM-Zulassungsrichtlinie autorisiert die Identität des Hauptkontos, die angeforderte Aktion auf der Google Cloud-Ressource auszuführen.

Unterstützte Haupt-IDs für die Identitätsföderation von Arbeitslasten für Flotten

In der folgenden Tabelle werden die Selektoren beschrieben, die Sie in IAM-Zulassungsrichtlinien verwenden können, um auf Hauptkonten in Flotten zu verweisen:

Typ der Hauptkonto-ID Syntax
Alle Pods, die ein bestimmtes Kubernetes-Dienstkonto verwenden Wählen Sie das Dienstkonto nach Name aus:
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Ersetzen Sie Folgendes:

  • PROJECT_NUMBER: Ihre numerische Projektnummer. Informationen zum Ermitteln der Projektnummer finden Sie unter Projekte identifizieren.
  • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
  • NAMESPACE: der Kubernetes-Namespace
  • SERVICEACCOUNT: Der Name des Kubernetes-Dienstkontos.

Dienstkonto anhand der UID auswählen
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Ersetzen Sie Folgendes:

  • PROJECT_NUMBER: Ihre numerische Projektnummer. Informationen zum Ermitteln der Projektnummer finden Sie unter Projekte identifizieren.
  • PROJECT_ID: Ihre Flottenprojekt-ID.
  • SERVICEACCOUNT_UID: die UID des ServiceAccount-Objekts auf dem API-Server.

Hinweis

  • Prüfen Sie, ob die folgenden Befehlszeilentools installiert sind:

    • Die neueste Version der Google Cloud CLI, die gcloud, das Befehlszeilentool für die Interaktion mit Google Cloud, enthält.
    • kubectl

    Wenn Sie Cloud Shell als Shell-Umgebung für die Interaktion mit Google Cloud verwenden, sind diese Tools für Sie installiert.

  • Achten Sie darauf, dass die gcloud CLI für die Verwendung mit Ihrem Projekt initialisiert wurde.

Cluster vorbereiten

Bevor Anwendungen in Ihrer Flotte eine föderierte Identität empfangen können, müssen die Cluster, in denen sie ausgeführt werden, in Ihrer Flotte registriert und ordnungsgemäß für die Verwendung von Workload Identity-Föderation der Flotte konfiguriert werden. In den folgenden Abschnitten wird beschrieben, wie Sie die Workload Identity-Föderation für Flotten für verschiedene Clustertypen einrichten.

GKE

Führen Sie für GKE-Cluster die folgenden Schritte aus:

  1. Aktivieren Sie die Workload Identity Federation for GKE, falls noch nicht aktiviert, in Ihrem Google Kubernetes Engine-Cluster.
  2. Registrieren Sie den Cluster in der Flotte:

Sie können die Workload Identity-Föderation für GKE auch beim Erstellen des Clusters und Registrieren der Flotte aktivieren.

Cluster außerhalb von Google Cloud

Bei den folgenden Clustertypen wird Workload Identity Federation für die Flotte automatisch aktiviert und sie werden bei der Clustererstellung bei Ihrer Flotte registriert:

  • Google Distributed Cloud (nur Software) auf VMware
  • Google Distributed Cloud (nur Software) auf Bare Metal
  • GKE on AWS
  • GKE on Azure

Verbundene Cluster

Angehängte EKS- und AKS-Cluster, die mit der GKE Multi-Cloud API registriert wurden, werden standardmäßig mit aktivierter Identitätsförderung von Arbeitslasten für Flotten registriert. Andere Aangehängte Cluster können mit aktivierter Workload Identity-Föderation der Flotte aktiviert werden, wenn sie die erforderlichen Anforderungen erfüllen. Folgen Sie der Anleitung für Ihren Clustertyp unter Cluster registrieren.

Identitätsföderation von Arbeitslasten für Flotten in Anwendungen verwenden

In den folgenden Schritten wird gezeigt, wie Sie eine Arbeitslast in einem registrierten Cluster für die Verwendung der Identitätsföderation von Arbeitslasten für Flotten konfigurieren:

  1. Ermitteln Sie den Namen des Workload Identity-Pools und des Identitätsanbieters Ihres Clusters:

    gcloud container fleet memberships describe MEMBERSHIP_ID \
        --project=FLEET_PROJECT_ID \
        --format="table(authority.identityProvider,authority.workloadIdentityPool,name)"
    

    Ersetzen Sie Folgendes:

    • MEMBERSHIP_ID: Der Name der Clustermitgliedschaft. Das ist oft der Name Ihres Clusters.
    • FLEET_PROJECT_ID: die Projekt-ID des Hostprojekts der Flotte.

    Die Ausgabe sieht in etwa so aus:

    IDENTITY_PROVIDER: IDENTITY_PROVIDER
    WORKLOAD_IDENTITY_POOL: WORKLOAD_IDENTITY_POOL
    NAME: projects/FLEET_PROJECT_ID/locations/MEMBERSHIP_LOCATION/memberships/MEMBERSHIP_ID
    

    Die Ausgabe enthält die folgenden Informationen:

    • IDENTITY_PROVIDER: den Identitätsanbieter für den Cluster.
    • MEMBERSHIP_LOCATION: Standort der Flottenmitgliedschaft. Dieser entspricht in der Regel dem Standort Ihres Clusters.
    • WORKLOAD_IDENTITY_POOL: der Name des Workload Identity-Pools, der mit Ihrer Flotte verknüpft ist. Dieser Wert hat die Syntax FLEET_PROJECT_ID.svc.id.goog.
  2. Erstellen Sie einen Kubernetes-Namespace. Sie können auch einen vorhandenen Namespace verwenden, einschließlich des Namespace default.

    kubectl create namespace NAMESPACE
    

    Ersetzen Sie NAMESPACE durch den Namen des Namespace.

  3. Erstellen Sie ein neues Kubernetes-Dienstkonto im Namespace: Sie können auch ein beliebiges vorhandenes Dienstkonto verwenden, einschließlich des default-Dienstkonto im Namespace.

    kubectl create serviceaccount KSA_NAME \
        --namespace=NAMESPACE
    

    Ersetzen Sie KSA_NAME durch den Namen des Dienstkonto.

  4. Speichern Sie das folgende Manifest als adc-config-map.yaml. Diese ConfigMap enthält die ADC-Konfiguration für Arbeitslasten.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      namespace: NAMESPACE
      name: my-cloudsdk-config
    data:
      config: |
        {
          "type": "external_account",
          "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER",
          "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
          "token_url": "https://sts.googleapis.com/v1/token",
          "credential_source": {
            "file": "/var/run/secrets/tokens/gcp-ksa/token"
          }
        }
    
  5. Stellen Sie die ConfigMap bereit:

    kubectl create -f adc-config-map.yaml
    
  6. Speichern Sie das folgende Manifest als workload-config.yaml:

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
      namespace:  NAMESPACE
    spec:
      serviceAccountName: KSA_NAME
      containers:
      - name: sample-container
        image: google/cloud-sdk:slim
        command: ["sleep","infinity"]
        env:
        - name: GOOGLE_APPLICATION_CREDENTIALS
          value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
        volumeMounts:
        - name: gcp-ksa
          mountPath: /var/run/secrets/tokens/gcp-ksa
          readOnly: true
      volumes:
      - name: gcp-ksa
        projected:
          defaultMode: 420
          sources:
          - serviceAccountToken:
              path: token
              audience: WORKLOAD_IDENTITY_POOL
              expirationSeconds: 172800
          - configMap:
              name: my-cloudsdk-config
              optional: false
              items:
              - key: "config"
                path: "google-application-credentials.json"
    

    Wenn Sie diese Arbeitslast bereitstellen, enthält das Volume gcp-ksa im Pod die folgenden Daten:

    Der Container im Pod stellt das Volume gcp-ksa unter dem Pfad /var/run/secrets/tokens/gcp-ksa bereit und konfiguriert ADC so, dass es in diesem Pfad nach der JSON-Datei für die Anmeldedatenkonfiguration sucht.

  7. Arbeitslast bereitstellen:

    kubectl apply -f workload-config.yaml
    

Alternative: Identitätswechsel für ein IAM-Dienstkonto

Alternativ können Sie Kubernetes-Dienstkonten in Ihren Clustern so konfigurieren, dass sie sich als IAM-Dienstkonten ausgeben und alle autorisierten Aktionen ausführen, die die IAM-Dienstkonten ausführen können. Dieser Ansatz kann den Wartungsaufwand erhöhen, da Sie die Verknüpfungen von Dienstkonten sowohl in IAM als auch in Kubernetes verwalten müssen.

In den meisten Fällen empfehlen wir, Kubernetes-Hauptkonten direkt in IAM-Zulassungsrichtlinien zu referenzieren, um Zugriff auf Google Cloud-Ressourcen zu gewähren. Folgen Sie dazu der Anleitung unter Workload Identity Federation für Flotten in Anwendungen verwenden.

  1. Ermitteln Sie den Namen des Workload Identity-Pools und des Identitätsanbieters Ihres Clusters:

    gcloud container fleet memberships describe MEMBERSHIP_ID \
        --project=FLEET_PROJECT_ID \
        --format="table(authority.identityProvider,authority.workloadIdentityPool,name)"
    

    Ersetzen Sie Folgendes:

    • MEMBERSHIP_ID: Der Name der Clustermitgliedschaft. Das ist oft der Name Ihres Clusters.
    • FLEET_PROJECT_ID: die Projekt-ID des Hostprojekts der Flotte.

    Die Ausgabe sieht in etwa so aus:

    IDENTITY_PROVIDER: IDENTITY_PROVIDER
    WORKLOAD_IDENTITY_POOL: WORKLOAD_IDENTITY_POOL
    NAME: projects/FLEET_PROJECT_ID/locations/MEMBERSHIP_LOCATION/memberships/MEMBERSHIP_ID
    

    Die Ausgabe enthält die folgenden Informationen:

    • IDENTITY_PROVIDER: den Identitätsanbieter für den Cluster.
    • MEMBERSHIP_LOCATION: Standort der Mitgliedschaft. Dieser entspricht in der Regel dem Standort Ihres Clusters.
    • WORKLOAD_IDENTITY_POOL: der Name des Workload Identity-Pools, der mit Ihrer Flotte verknüpft ist. Dieser Wert hat die Syntax FLEET_PROJECT_ID.svc.id.goog.
  2. Erstellen Sie ein IAM-Dienstkonto, das Ihre Anwendung imitieren kann. Sie können auch ein vorhandenes IAM-Dienstkonto verwenden.

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

    Ersetzen Sie Folgendes:

    • IAM_SA_NAME: Der Name Ihres IAM-Dienstkontos.
    • IAM_SA_PROJECT_ID: die Projekt-ID des Projekts, das Ihr IAM-Dienstkonto enthält. Diese kann sich von der Ihres Flotten-Hostprojekts unterscheiden.
  3. Gewähren Sie dem IAM-Dienstkonto alle erforderlichen Berechtigungen für den Zugriff auf Google Cloud APIs. Fügen Sie dazu die erforderlichen IAM-Zulassungsrichtlinien hinzu. Dazu können Sie gcloud iam service-accounts add-iam-policy-binding oder eine andere Methode verwenden. In der Dokumentation der einzelnen Dienste können Sie nachlesen, welche Berechtigungen für die Verwendung von Google Cloud APIs erforderlich sind. Eine vollständige Liste vordefinierter Rollen mit den erforderlichen Berechtigungen finden Sie unter Informationen zu Rollen.

  4. Erstellen Sie ein Kubernetes-Dienstkonto in einem Namespace. Sie können auch ein vorhandenes Kubernetes-Dienstkonto und einen beliebigen Namespace verwenden, einschließlich des default-Dienstkontos und des default-Namespace.

    kubectl create serviceaccount KSA_NAME \
        --namespace=NAMESPACE
    

    Ersetzen Sie Folgendes:

    • KSA_NAME: der Name des Dienstkonto.
    • NAMESPACE: der Name des Namespace.
  5. Erstellen Sie eine IAM-Zulassungsrichtlinie, die es einem Kubernetes-Dienstkonto in einem bestimmten Namespace in Ihrem Cluster ermöglicht, 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 \
        --project=IAM_SA_PROJECT_ID \
        --role=roles/iam.workloadIdentityUser \
        --member="serviceAccount:WORKLOAD_IDENTITY_POOL[NAMESPACE/KSA_NAME]"
    

    Ersetzen Sie WORKLOAD_IDENTITY_POOL durch den Namen des Workload Identity-Pools.

  6. Speichern Sie das folgende Manifest als adc-config-map.yaml. Diese ConfigMap enthält die ADC-Konfiguration für Arbeitslasten.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      namespace: K8S_NAMESPACE
      name: my-cloudsdk-config
    data:
      config: |
        {
          "type": "external_account",
          "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER",
          "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/IAM_SA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com:generateAccessToken",
          "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
          "token_url": "https://sts.googleapis.com/v1/token",
          "credential_source": {
            "file": "/var/run/secrets/tokens/gcp-ksa/token"
          }
        }
    

    Ersetzen Sie Folgendes:

    • IAM_SA_NAME: der Name des IAM-Dienstkontos, das imitiert werden soll.
    • IAM_SA_PROJECT_ID ist die Projekt-ID des IAM-Dienstkontos.
  7. Speichern Sie das folgende Manifest als workload-config.yaml:

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
      namespace:  K8S_NAMESPACE
    spec:
      serviceAccountName: KSA_NAME
      containers:
      - name: my-container
        image: my-image
        command: ["sleep","infinity"]
        env:
          - name: GOOGLE_APPLICATION_CREDENTIALS
            value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
        volumeMounts:
        - name: gcp-ksa
          mountPath: /var/run/secrets/tokens/gcp-ksa
          readOnly: true
      volumes:
      - name: gcp-ksa
        projected:
          defaultMode: 420
          sources:
          - serviceAccountToken:
              path: token
              audience: WORKLOAD_IDENTITY_POOL
              expirationSeconds: 172800
          - configMap:
              name: my-cloudsdk-config
              optional: false
              items:
                - key: "config"
                  path: "google-application-credentials.json"
    
    

    Wenn Sie diese Arbeitslast bereitstellen, enthält das Volume gcp-ksa im Pod die folgenden Daten:

    Der Container im Pod stellt das Volume gcp-ksa unter dem Pfad /var/run/secrets/tokens/gcp-ksa bereit und konfiguriert ADC so, dass es in diesem Pfad nach der JSON-Datei für die Anmeldedatenkonfiguration sucht.

  8. Arbeitslast bereitstellen:

    kubectl apply -f workload-config.yaml
    

Einrichtung der Workload Identity-Föderation für die Flotte prüfen

In diesem Abschnitt erstellen Sie einen Cloud Storage-Bucket und greifen von einem Pod aus darauf zu, der die Workload Identity Federation der Flotte verwendet. Bevor Sie diese Schritte ausführen, müssen Sie die Identitätsföderation von Arbeitslasten konfiguriert haben. Folgen Sie dazu der Anleitung im Abschnitt Identitätsföderation von Arbeitslasten für Flotten in Anwendungen verwenden.

In diesem Abschnitt wird nicht beschrieben, wie Sie die Workload Identity-Föderation mit der Methode zur Identitätsübernahme von IAM-Dienstkonten überprüfen.

  1. So finden Sie Ihre numerische Projektnummer:

    gcloud projects describe FLEET_PROJECT_ID \
        --format="value(projectNumber)"
    

    Die Ausgabe sieht in etwa so aus:

    1234567890
    
  2. Erstellen Sie einen Cloud Storage-Bucket:

    gcloud storage buckets create gs://FLEET_PROJECT_ID-test-bucket \
        --location=LOCATION
    

    Ersetzen Sie LOCATION durch einen Google Cloud-Standort.

  3. Erstellen Sie eine IAM-Zulassungsrichtlinie, die dem von Ihnen erstellten Dienstkonto Zugriff auf den Bucket gewährt:

    gcloud storage buckets add-iam-policy-binding gs://FLEET_PROJECT_ID-test-bucket \
        --condition=None \
        --role=roles/storage.objectViewer \
        --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME
    

    Ersetzen Sie Folgendes:

    • FLEET_PROJECT_NUMBER: Ihre numerische Projektnummer.
    • FLEET_PROJECT_ID: Ihre Projekt-ID.
    • NAMESPACE: der Name des Kubernetes-Namespace, in dem der Pod aus dem vorherigen Abschnitt ausgeführt wird.
    • KSA_NAME: der Name des Kubernetes-Dienstkontos, das Ihr Pod aus dem vorherigen Abschnitt verwendet.
  4. Öffnen Sie eine Shell-Sitzung im Pod:

    kubectl exec -it pods/my-pod --namespace=NAMESPACE -- /bin/bash
    
  5. Versuchen Sie, die Objekte im Bucket aufzulisten:

    curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://storage.googleapis.com/storage/v1/b/test-bucket/o"
    

    Die Ausgabe sieht so aus:

    {
      "kind": "storage#objects"
    }
    

Über Ihren Code authentifizieren

Wenn Sie Cloud-Clientbibliotheken verwenden, suchen Authentifizierungsbibliotheken automatisch mit ADC nach Anmeldedaten, um sich bei Google Cloud-Diensten zu authentifizieren. Sie müssen Cloud-Clientbibliotheken verwenden, die die Workload Identity-Föderation unterstützen. Im Folgenden werden die erforderlichen Mindestversionen für Cloud-Clientbibliotheken und eine Anleitung zum Prüfen Ihrer aktuellen Version aufgeführt:

C++

Die meisten Google Cloud-Clientbibliotheken für C++ unterstützen die Identitätsföderation mithilfe eines ChannelCredentials-Objekts, das durch Aufrufen von grpc::GoogleDefaultCredentials() erstellt wird. Zur Initialisierung dieser Anmeldedaten müssen Sie die Clientbibliotheken ab Version 1.36.0 von gRPC erstellen.

Da die Cloud Storage-Clientbibliothek für C++ die REST API und nicht gRPC verwendet, wird die Identitätsföderation nicht unterstützt.

Go

Clientbibliotheken für Go unterstützen die Identitätsföderation, 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, 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 Identitätsfö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, wenn sie Version 1.7.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.

Nächste Schritte

Best Practices für die Organisation Ihrer Flotten bei Verwendung der Workload Identity-Föderation der Flotte