Diese Seite wurde von der Cloud Translation API übersetzt.

Über Workloads der Flotte mit gemischten Vertrauensstufen 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 mit einem gemischten Vertrauensmodell in der gesamten Flotte authentifizieren. Wenn Ihre Flotte ein gemeinsames Vertrauensmodell hat, lesen Sie den Abschnitt Über Workloads der Flotte mit gemeinsamem Vertrauensmodell bei Google Cloud -APIs authentifizieren.

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 unterschiedlichen Vertrauensstufen

Mit der Fleet Workload Identity-Föderation können Sie IAM-Rollen fürGoogle Cloud -APIs und -Ressourcen an Entitäten in Ihrer Flotte, z. B. Arbeitslasten in einem bestimmten Namespace, vergeben. Standardmäßig wird in Ihrem Flotten-Hostprojekt ein von Google verwalteter Workload Identity-Pool verwendet, um Identitäten für Entitäten in der gesamten Flotte bereitzustellen. In Umgebungen mit unterschiedlichen Vertrauensstufen wie Multi-Tenant-Flotten oder in Flotten-Hostprojekten, in denen eigenständige Cluster ausgeführt werden, empfehlen wir jedoch, einen separaten selbstverwalteten Workload Identity-Pool für eine Teilmenge Ihrer Arbeitslasten und Cluster zu konfigurieren.

Entitäten, die einen selbstverwalteten Workload Identity-Pool verwenden, haben in IAM-Richtlinien andere Kennungen als Entitäten, die den von Google verwalteten Workload Identity-Pool des Flotten-Hostprojekts verwenden. So wird sichergestellt, dass durch das Gewähren des Zugriffs auf Hauptkonten in einem bestimmten Flotten-Namespace nicht unbeabsichtigt Zugriff auf andere Hauptkonten gewährt wird, die mit der Kennung übereinstimmen.

Für selbstverwaltete Workload Identity-Pools müssen Sie Teambereiche verwenden. Mit Teambereichen können Sie den Zugriff auf Teilmengen von Flottenressourcen für einzelne Teams steuern. Sie binden bestimmte Teambereiche an bestimmte Flottenmitgliedscluster, damit das Team Arbeitslasten in diesen Clustern bereitstellen kann. Innerhalb eines Teambereichs können Teammitglieder Arbeitslasten nur in Flotten-Namespaces bereitstellen.

Die Verwendung von selbstverwalteten Workload Identity-Pools zur Bereitstellung von Identitäten für Arbeitslasten mit Teambereich bietet folgende Vorteile:

Achten Sie darauf, dass Zugriffsberechtigungen für Entitäten in Flotten-Namespaces nicht unbeabsichtigt auf Entitäten in anderen Namespaces oder Clustern angewendet werden.
Konfigurieren Sie eine Reihe von Flottenclustern, um Identitäten aus dem selbstverwalteten Pool abzurufen, indem Sie sie an einen Teambereich binden und den selbstverwalteten Pool als Identitätsanbieter in diesen Clustern einrichten.
Konfigurieren Sie eine Teilmenge der gebundenen Cluster eines Teambereichs, um Identitäten aus dem selbstverwalteten Pool abzurufen, indem Sie den selbstverwalteten Pool nur in bestimmten Clustern als Identitätsanbieter einrichten.

Beispiel für Identitätsgleichheit in einer Umgebung mit unterschiedlichen Vertrauensstufen

Stellen Sie sich folgendes Szenario vor:

Sie haben zwei Flottenmitgliedscluster: frontend-cluster und finance-cluster.
Sie haben keinen selbstverwalteten Workload Identity-Pool konfiguriert.
Sie erstellen einen finance-team-Teambereich und einen finance-ns-Flotten-Namespace im Teambereich.
Sie binden den finance-cluster-Cluster an den Teambereich finance-team.
Sie gewähren dem Kubernetes-Dienstkonto finance-sa im Flotten-Namespace finance-ns eine IAM-Rolle.

Alle Arbeitslasten, die die folgenden Kriterien erfüllen, haben dieselbe Identität:

Im Flotten-Namespace finance-ns ausführen.
Verwenden Sie das finance-sa-Dienstkonto.

Wenn jedoch jemand im frontend-cluster-Cluster einen finance-ns-Kubernetes-Namespace und ein finance-sa-ServiceAccount erstellt, erhalten sie dieselbe Identität wie die Arbeitslasten im finance-cluster-Cluster. Das liegt daran, dass die gesamte Flotte den von Google verwalteten Workload Identity-Pool des Flotten-Host-Projekts verwendet und die Prinzipal-ID keinen Host-Cluster angibt.

Stellen Sie sich die folgenden Änderungen am vorherigen Szenario vor:

Sie richten einen selbstverwalteten Workload Identity-Pool in Ihrer Flotte ein.
Sie konfigurieren den finance-cluster-Cluster so, dass er Identitäten aus dem selbstverwalteten Pool anstelle des von Google verwalteten Pools abruft.
Sie erstellen eine IAM-Rollenzuweisung, in der der selbstverwaltete Pool in der Hauptkonto-ID anstelle des von Google verwalteten Pools angegeben wird.

Die Arbeitslasten, die im Flotten-Namespace finance-ns in finance-cluster ausgeführt werden, erhalten jetzt eine Identität aus dem selbstverwalteten Pool. Entitäten im Kubernetes-Namespace finance-ns im Cluster frontend-cluster erhalten jedoch weiterhin Identitäten aus dem von Google verwalteten Workload Identity-Pool des Flotten-Host-Projekts.

Diese Änderungen haben folgende Vorteile:

Sie können Entitäten im finance-ns-Flottennamespace explizit Rollen zuweisen.
Entitäten im frontend-cluster-Cluster können nicht denselben Zugriff erhalten, da die Identitäten im frontend-cluster-Cluster aus dem von Google verwalteten Workload Identity-Pool stammen.

Hinweise

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.

Voraussetzungen

Sie müssen Funktionen zur Flottenteamverwaltung wie Teambereiche und Flotten-Namespaces in Ihrer Flotte verwenden. In der Anleitung auf dieser Seite erfahren Sie, wie Sie einen Beispiel-Teambereich und einen Flotten-Namespace konfigurieren.

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.

IAM Workload Identity-Pool einrichten

In diesem Abschnitt erstellen Sie einen neuen IAM Workload Identity-Pool im Flotten-Hostprojekt und gewähren dem Flotten-Dienst-Agent Zugriff auf den neuen Pool.

So erstellen Sie einen Workload Identity-Pool:
```
gcloud iam workload-identity-pools create POOL_NAME \
    --location=global \
    --project=POOL_HOST_PROJECT_ID \
    --mode=TRUST_DOMAIN
```
Ersetzen Sie Folgendes:
- POOL_NAME: der Name des neuen Workload Identity-Pools.
- POOL_HOST_PROJECT_ID: die Projekt-ID des Projekts, in dem Sie den selbstverwalteten Workload Identity-Pool erstellen möchten. Sie können ein beliebiges Google Cloud -Projekt verwenden, einschließlich Ihres Flotten-Hostprojekts.

Weisen Sie dem Flottendienst-Agent die IAM Workload Identity Pool Admin-Rolle (roles/iam.workloadIdentityPoolAdmin) für den neuen Workload Identity-Pool zu:

gcloud iam workload-identity-pools add-iam-policy-binding POOL_NAME \
    --project=POOL_HOST_PROJECT_ID \
    --location=global \
    --member=serviceAccount:service-FLEET_HOST_PROJECT_NUMBER@gcp-sa-gkehub.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityPoolAdmin \
    --condition=None

Ersetzen Sie FLEET_HOST_PROJECT_NUMBER durch die Projektnummer des Flotten-Hostprojekts.

Selbstverwalteten Pool zur Flottenkonfiguration hinzufügen

In diesem Abschnitt aktivieren Sie selbstverwaltete Pools mit der Workload Identity Federation der Flotte und fügen der Flottenkonfiguration den Pool hinzu, den Sie erstellt haben. Dieser Abschnitt enthält auch eine Anleitung zum Erstellen eines neuen Teambereichs und eines Flotten-Namespace. Wenn in Ihrer Flotte bereits Teambereiche und Flotten-Namespaces konfiguriert sind, überspringen Sie diese Schritte.

Aktivieren Sie die Identitätsföderation von Arbeitslasten für Flotten auf Flottenebene:
```
gcloud beta container fleet workload-identity enable \
  --project=FLEET_HOST_PROJECT_ID
```
Ersetzen Sie FLEET_HOST_PROJECT_ID durch die Projekt-ID des Flotten-Hostprojekts.
Fügen Sie den selbstverwalteten Workload Identity-Pool der Flottenkonfiguration hinzu:
```
gcloud beta container fleet workload-identity scope-tenancy-pool set POOL_NAME
```
Ersetzen Sie POOL_NAME durch den Namen Ihres selbstverwalteten Workload Identity-Pools. Dieser Wert hat die folgende Syntax:
```
POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
```
Erstellen Sie einen neuen Teambereich. Wenn Sie bereits einen Teambereich und einen Flotten-Namespace haben, fahren Sie mit dem Abschnitt Workload Identity-Poolkonfiguration prüfen fort.
```
gcloud container fleet scopes create SCOPE_NAME
```
Ersetzen Sie SCOPE_NAME durch den Namen des neuen Teambereichs.
So erstellen Sie einen neuen Flotten-Namespace im Teambereich:
```
gcloud container fleet scopes namespaces create NAMESPACE_NAME \
    --scope=SCOPE_NAME
```
Ersetzen Sie NAMESPACE_NAME durch den Namen Ihres neuen Flotten-Namespace.
Binden Sie einen Cluster in Ihrer Flotte an den Teambereich:
```
gcloud container fleet memberships bindings create BINDING_NAME \
    --membership=FLEET_CLUSTER_NAME \
    --location=global \
    --scope=SCOPE_NAME
```
Ersetzen Sie Folgendes:
- BINDING_NAME: der Name der neuen Mitgliedschaftsbindung.
- FLEET_CLUSTER_NAME: Der Name des vorhandenen Flottenclusters, der an den Teambereich gebunden werden soll.

Workload Identity-Pool-Konfiguration prüfen

In diesem Abschnitt prüfen Sie, ob die Konfiguration Ihres selbstverwalteten Workload Identity-Pools erfolgreich war.

Beschreiben Sie die Konfiguration der Flottenmitgliedschaft:
```
gcloud container fleet memberships describe FLEET_CLUSTER_NAME \
    --location=global
```
Ersetzen Sie FLEET_CLUSTER_NAME durch den Namen eines vorhandenen Flottenclusters, der an einen beliebigen Teambereich in Ihrer Flotte gebunden ist.

Die Ausgabe sieht etwa so aus:
```
authority:
...
  scopeTenancyIdentityProvider: https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME
  scopeTenancyWorkloadIdentityPool: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
  workloadIdentityPool: FLEET_HOST_PROJECT_ID.svc.id.goog
...
```
Diese Ausgabe sollte die folgenden Felder enthalten:
- scopeTenancyIdentityProvider: Der Identitätsanbieter für Arbeitslasten, die in Flotten-Namespaces innerhalb von Teambereichen ausgeführt werden. Der Wert ist ein Ressourcen-Identifier für Ihren Cluster.
- scopeTenancyWorkloadIdentityPool: Der Workload Identity-Pool, aus dem Arbeitslasten in Flotten-Namespaces innerhalb von Teambereichen Kennungen erhalten. Der Wert ist Ihr selbstverwalteter Workload Identity-Pool im Format POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog.
- workloadIdentityPool: der Name des von Google verwalteten Workload Identity-Pools des Hostprojekts der Flotte, aus dem standardmäßig alle anderen Workloads in der Flotte Identitäten erhalten.

Optional: Prüfen Sie, ob Ihr Workload Identity-Pool einen Namespace mit demselben Namen wie Ihr Flotten-Namespace hat:

gcloud iam workload-identity-pools namespaces list \
    --workload-identity-pool=POOL_NAME \
    --location=global

Die Ausgabe sieht etwa so aus:

---
description: Fleet namespace NAMESPACE_NAME
name: projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME/namespaces/NAMESPACE_NAME
state: ACTIVE

Ihre Flotte kann jetzt den selbstverwalteten Workload Identity-Pool verwenden, um Identitäten für Arbeitslasten abzurufen, die in Flotten-Namespaces ausgeführt werden. Wenn Sie den selbstverwalteten Pool verwenden möchten, konfigurieren Sie, wie bestimmte Cluster Identitäten erhalten, wie im nächsten Abschnitt beschrieben.

Arbeitslasten für die Verwendung von selbstverwalteten Pools für Identitäten konfigurieren

Damit Arbeitslasten den selbstverwalteten Pool verwenden, konfigurieren Sie bestimmte Flottennamespaces in Flottenmitgliedsclustern mit einer Kubernetes-ConfigMap. Mit dieser cluster- und namespacebezogenen Konfiguration können Sie den Umfang der Zugriffsberechtigungen weiter einschränken, von gesamten Flotten-Namespaces auf Arbeitslasten, die in bestimmten Flotten-Namespaces in bestimmten Clustern ausgeführt werden.

Stellen Sie eine Verbindung zu Ihrem Flottenmitgliedscluster her:
```
gcloud container clusters get-credentials FLEET_CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CLUSTER_LOCATION
```
Ersetzen Sie Folgendes:
- FLEET_CLUSTER_NAME: Der Name eines Flottenmitgliedsclusters, der bereits an einen Teambereich gebunden ist.
- CLUSTER_PROJECT_ID: die Projekt-ID des Clusterprojekts.
- CLUSTER_LOCATION: Der Standort des Clusters.

Rufen Sie den vollständigen Namen des selbstverwalteten Workload Identity-Pools ab. Sie benötigen sie später.

kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_workload_identity_pool"

Die Ausgabe sieht etwa so aus:

POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog

Rufen Sie den Namen des Identitätsanbieters für Teambereiche ab. Sie benötigen ihn später.

kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_identity_provider"

Die Ausgabe sieht etwa so aus:

https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME

Speichern Sie das folgende YAML-Manifest für eine ConfigMap in einem Texteditor als self-managed-pool.yaml:
```
kind: ConfigMap
apiVersion: v1
metadata:
  namespace: NAMESPACE_NAME
  name: google-application-credentials
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:SELF_MANAGED_POOL_FULL_NAME: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"
      }
    }
```
Ersetzen Sie Folgendes:
- NAMESPACE_NAME: der Name des Flotten-Namespace.
- SELF_MANAGED_POOL_FULL_NAME: der vollständige Name des selbstverwalteten Workload Identity-Pools aus der Ausgabe der vorherigen Schritte in diesem Abschnitt. Beispiel: example-pool.global.1234567890.workload.id.goog
- IDENTITY_PROVIDER: Der Name des Identitätsanbieters aus der Ausgabe der vorherigen Schritte in diesem Abschnitt. Beispiel: https://gkehub.googleapis.com/projects/1234567890/locations/global/memberships/example-cluster.
Stellen Sie die ConfigMap in Ihrem Cluster bereit:
```
kubectl create -f self-managed-pool.yaml
```

Durch das Bereitstellen der ConfigMap wird GKE mitgeteilt, dass Arbeitslasten in diesem Namespace den selbstverwalteten Workload Identity-Pool verwenden sollen, um Identitäten abzurufen.

Hauptkonten IAM-Rollen gewähren

In diesem Abschnitt erstellen Sie ein Kubernetes-Dienstkonto in einem Fleet-Namespace und weisen dem Dienstkonto eine IAM-Rolle zu. Pods, die dieses Dienstkonto verwenden, können dann auf die Google Cloud -Ressourcen zugreifen, für die Sie die Rolle gewähren.

Erstellen Sie ein Kubernetes-Dienstkonto im Namespace Ihrer Flotte:
```
kubectl create serviceaccount SERVICEACCOUNT_NAME \
    --namespace=NAMESPACE_NAME
```
Ersetzen Sie Folgendes:
- SERVICEACCOUNT_NAME: der Name des neuen ServiceAccount.
- NAMESPACE_NAME: der Name des Flotten-Namespace.

Weisen Sie dem Dienstkonto eine IAM-Rolle zu. Mit dem folgenden Beispielbefehl wird dem ServiceAccount die Rolle „Storage-Objekt-Betrachter“ (roles/storage.objectViewer) für einen Bucket zugewiesen:

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME \
    --role=roles/storage.objectViewer \
    --condition=None

Das Flag member enthält die Hauptkonto-ID für das neue ServiceAccount, das Sie erstellt haben. Die Anfragen, die Ihre Arbeitslasten an Google Cloud-APIs senden, verwenden ein Verbundzugriffstoken. Dieses föderierte Zugriffstoken enthält die Hauptkonto-ID der Entität, die die Anfrage sendet. Wenn das Hauptkonto in einer Zulassungsrichtlinie, die eine Rolle für die Zielressource gewährt, mit dem Hauptkonto im föderierten Zugriffstoken übereinstimmt, kann die Authentifizierung und Autorisierung fortgesetzt werden.

Arbeitslasten bereitstellen, die den selbstverwalteten Pool verwenden

Kubernetes-Manifeste, die Sie in Ihrem Flotten-Namespace anwenden, müssen so konfiguriert sein, dass sie Identitäten aus dem selbstverwalteten Pool abrufen. Die Arbeitslasten, die Sie bereitstellen und die Google Cloud -APIs aufrufen müssen, sollten die folgenden Felder enthalten:

metadata.namespace: der Name des Flotten-Namespace.
spec.serviceAccountName: der Name des Kubernetes-ServiceAccounts im Flottennamespace.
spec.containers.env: Eine Umgebungsvariable mit dem Namen GOOGLE_APPLICATION_CREDENTIALS, die den Pfad zur Datei mit den Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) angibt.
spec.containers.volumeMounts: Ein schreibgeschütztes Volume, mit dem der Container das Bearer-Token für das Dienstkonto verwenden kann.
spec.volumes: Ein projiziertes Volume, das ein ServiceAccount-Token im Pod bereitstellt. Die Zielgruppe des Tokens ist der selbstverwaltete Workload Identity-Pool. Die ConfigMap, die die Konfiguration der Identitätsföderation von Arbeitslasten für die Flotte enthält, ist eine Quelle für das Volume.

Ein Beispiel für eine korrekt konfigurierte Manifestdatei finden Sie im Abschnitt Authentifizierung über eine Arbeitslast prüfen.

Authentifizierung über eine Arbeitslast prüfen

In diesem Abschnitt finden Sie eine optionale Anleitung, mit der Sie prüfen können, ob Sie den selbstverwalteten Workload Identity-Pool richtig konfiguriert haben. Dazu listen Sie den Inhalt eines Beispiel-Cloud Storage-Bucket auf. Sie erstellen einen Bucket, weisen einem Dienstkonto in einem Flotten-Namespace eine Rolle für den Bucket zu und stellen einen Pod bereit, um auf den Bucket zuzugreifen.

Erstellen Sie einen Cloud Storage-Bucket:

gcloud storage buckets create gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --location=LOCATION \
    --project=FLEET_HOST_PROJECT_ID

Weisen Sie dem Dienstkonto im Flotten-Namespace die Rolle roles/storage.objectViewer für den Bucket zu:
```
gcloud storage buckets add-iam-policy-binding gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --condition=None \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME
```
Ersetzen Sie Folgendes:
- FLEET_HOST_PROJECT_NUMBER: die Projektnummer Ihres Flotten-Hostprojekts.
- POOL_NAME: der Name Ihres selbstverwalteten Workload Identity-Pools.
- NAMESPACE_NAME: Der Name des Flotten-Namespace, in dem Sie den Pod ausführen möchten.
- SERVICEACCOUNT_NAME: der Name des Kubernetes-ServiceAccount, das der Pod verwenden soll.

Speichern Sie das folgende Manifest als pod-bucket-access.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: bucket-access-pod
  namespace:  NAMESPACE_NAME
spec:
  serviceAccountName: SERVICEACCOUNT_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: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
          - key: "config"
            path: "google-application-credentials.json"

Ersetzen Sie Folgendes:

NAMESPACE_NAME: Der Name des Flotten-Namespace, in dem Sie den Pod ausführen möchten.
SERVICEACCOUNT_NAME: der Name des Kubernetes-ServiceAccount, das der Pod verwenden soll.
POOL_NAME: der Name Ihres selbstverwalteten Workload Identity-Pools.
FLEET_HOST_PROJECT_NUMBER: die Projektnummer Ihres Flotten-Hostprojekts.

Stellen Sie den Pod in Ihrem Cluster bereit:

kubectl apply -f pod-bucket-access.yaml

Öffnen Sie eine Shell-Sitzung im Pod:

kubectl exec -it bucket-access-pod -n NAMESPACE_NAME -- /bin/bash

Versuchen Sie, 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_HOST_PROJECT_ID-workload-id-bucket/o"

Die Ausgabe sieht so aus:

{
  "kind": "storage#objects"
}

Optional können Sie prüfen, ob ein ähnlicher Namespace und ein ähnliches Dienstkonto in einem anderen Flottenmitgliedscluster nicht dieselbe Identität beanspruchen können. Führen Sie in einem Cluster, der die Identitätsföderation von Arbeitslasten für die Flotte verwendet, aber keinen Flotten-Namespace oder eine selbstverwaltete Poolkonfiguration hat, die folgenden Schritte aus:

Erstellen Sie einen neuen Kubernetes-Namespace mit demselben Namen wie der Flotten-Namespace, in dem Sie den selbstverwalteten Workload Identity-Pool eingerichtet haben.
Erstellen Sie ein neues Kubernetes-Dienstkonto mit demselben Namen wie das Dienstkonto, dem Sie in den vorherigen Abschnitten eine IAM-Rolle zugewiesen haben.
Stellen Sie einen Pod bereit, der dasselbe Dienstkonto und denselben Namespace verwendet, für den im Feld spec.volumes.projected.sources.serviceAccountToken jedoch der von Google verwaltete Workload Identity-Pool angegeben ist. Dieser Pool hat die folgende Syntax:
```
FLEET_HOST_PROJECT_ID.svc.id.goog
```
Versuchen Sie, über eine Shell-Sitzung im Pod auf den Cloud Storage-Bucket zuzugreifen.

Die Ausgabe sollte ein 401: Unauthorized-Fehler sein, da sich die Prinzipal-ID für den Pod, der den von Google verwalteten Workload Identity-Pool verwendet, von der Prinzipal-ID für den Pod unterscheidet, der den selbstverwalteten Pool verwendet.

Über Workloads der Flotte mit gemischten Vertrauensstufen bei Google Cloud APIs authentifizieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Informationen zur Identitätsföderation von Arbeitslasten für Flotten für Umgebungen mit unterschiedlichen Vertrauensstufen

Beispiel für Identitätsgleichheit in einer Umgebung mit unterschiedlichen Vertrauensstufen

Hinweise

Voraussetzungen

Cluster vorbereiten

GKE

Cluster außerhalb von Google Cloud

Verbundene Cluster

IAM Workload Identity-Pool einrichten

Selbstverwalteten Pool zur Flottenkonfiguration hinzufügen

Workload Identity-Pool-Konfiguration prüfen

Arbeitslasten für die Verwendung von selbstverwalteten Pools für Identitäten konfigurieren

Hauptkonten IAM-Rollen gewähren

Arbeitslasten bereitstellen, die den selbstverwalteten Pool verwenden

Authentifizierung über eine Arbeitslast prüfen

Nächste Schritte

Über Workloads der Flotte mit gemischten Vertrauensstufen bei Google Cloud APIs authentifizieren