Diese Seite wurde von der Cloud Translation API übersetzt.

Über Workloads der Flotte mit gemeinsamem Vertrauen bei Google Cloud-APIs authentifizieren

Auf dieser Seite erfahren Sie, wie Sie Ihre Anwendungen so konfigurieren, dass sie sich beiGoogle Cloud -APIs wie der Compute Engine API oder der AI Platform API von Flotten authentifizieren, die ein gemeinsames Vertrauensmodell für die gesamte Flotte haben. Wenn Ihre Flotte ein gemischtes Vertrauensmodell hat, lesen Sie den Abschnitt Über Workloads der Flotte mit gemischtem Vertrauensmodell bei Google Cloud -APIs authentifizieren (Vorabversion).

Diese Seite richtet sich an Plattformadministratoren und ‑betreiber sowie an Sicherheitsexperten, die sich programmatisch über Flottenarbeitslasten bei Google Cloud-APIs authentifizieren möchten. Weitere Informationen zu den Nutzerrollen und Beispielaufgaben, auf die wir in der Google Cloud-Dokumentation verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Konzepten vertraut:

Informationen zur Identitätsföderation von Arbeitslasten für Flotten für Umgebungen mit gemeinsamem Vertrauen

Mit der Workload Identity-Föderation für Flotten können Sie sich mit integrierten Google Cloud und Kubernetes-Authentifizierungsmechanismen beiGoogle Cloud APIs authentifizieren. Durch die Workload Identity-Föderation für Flotten ist es nicht mehr erforderlich, weniger sichere Methoden wie das Einbinden von Zugriffstokens in Pods oder das Speichern von Anmeldedaten mit langer Gültigkeitsdauer zu verwenden.

Standardmäßig verwendet Ihr Flotten-Hostprojekt einen von Google verwalteten Workload Identity-Pool, um Identitäten für Entitäten in der gesamten Flotte bereitzustellen. Jede Identität in der Flotte oder im Flotten-Hostprojekt, die dieselbe IAM-Kennung hat, wird von IAM als dieselbe Identität betrachtet. Diese implizite Identitätsgleichheit ist nützlich, wenn Sie in Umgebungen mit gemeinsamem Vertrauen, z. B. Flotten mit einem einzelnen Mandanten, im großen Maßstab Zugriff gewähren. In solchen Umgebungen spielt es keine Rolle, ob andere Entitäten unbeabsichtigt ähnliche Berechtigungen für Ressourcen erhalten.

Vorbereitung

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 Cloudverwenden, 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:

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 angehä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 Syntax FLEET_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.

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 aufGoogle 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 Syntax FLEET_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 des default-Namespace.
```
kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE
```
Ersetzen Sie Folgendes:
- KSA_NAME: der Name des ServiceAccount.
- 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.

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.
Best Practice: Erstellen Sie IAM-Zulassungsrichtlinien, die die geringste Anzahl von Berechtigungen für die jeweilige Ressource gewähren, auf die die Arbeitslast zugreifen muss.

Ö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 application-default print-access-token)" \
"https://storage.googleapis.com/storage/v1/b/FLEET_PROJECT_ID-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 Client Libraries for 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