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
oderprincipalSet
, 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-HostprojektsSELECTOR
: 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:
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.
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.
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.
- Die Umgebungsvariable
Wenn die Arbeitslast einen Google Cloud API-Aufruf ausführt, geschieht Folgendes:
- 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. - 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.
- ADC fügt das föderierte Token in die API-Anfrage ein.
- 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/ Ersetzen Sie Folgendes:
Dienstkonto anhand der UID auswählen principal://iam.googleapis.com/projects/ Ersetzen Sie Folgendes:
|
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.
- Die neueste Version der Google Cloud CLI, die
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:
- Aktivieren Sie die Workload Identity Federation for GKE, falls noch nicht aktiviert, in Ihrem Google Kubernetes Engine-Cluster.
- 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:
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 SyntaxFLEET_PROJECT_ID.svc.id.goog
.
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.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.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" } }
Stellen Sie die ConfigMap bereit:
kubectl create -f adc-config-map.yaml
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:- Die Daten in der ConfigMap, die Sie als Datei mit dem Namen
google-application-credentials.json
bereitgestellt haben. Diese Datei ist eine Konfigurationsdatei für ADC-Anmeldedaten. - Das Token des Kubernetes-Dienstkontos als
token
. Kubernetes stellt ein signiertes JWT für das Dienstkonto als projizierte Tokendatei für das Dienstkonto bereit.
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.- Die Daten in der ConfigMap, die Sie als Datei mit dem Namen
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.
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 SyntaxFLEET_PROJECT_ID.svc.id.goog
.
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.
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.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 desdefault
-Namespace.kubectl create serviceaccount KSA_NAME \ --namespace=NAMESPACE
Ersetzen Sie Folgendes:
KSA_NAME
: der Name des Dienstkonto.NAMESPACE
: der Name des Namespace.
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.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.
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:- Die Daten in der ConfigMap, die Sie als Datei mit dem Namen
google-application-credentials.json
bereitgestellt haben. Diese Datei ist eine Konfigurationsdatei für ADC-Anmeldedaten. - Das Token des Kubernetes-Dienstkontos als
token
. Kubernetes stellt ein signiertes JWT für das Dienstkonto als projizierte Tokendatei für das Dienstkonto bereit.
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.- Die Daten in der ConfigMap, die Sie als Datei mit dem Namen
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.
So finden Sie Ihre numerische Projektnummer:
gcloud projects describe FLEET_PROJECT_ID \ --format="value(projectNumber)"
Die Ausgabe sieht in etwa so aus:
1234567890
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.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.
Öffnen Sie eine Shell-Sitzung im Pod:
kubectl exec -it pods/my-pod --namespace=NAMESPACE -- /bin/bash
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