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

Auf dieser Seite erfahren Sie, wie Sie Ihre Anwendungen so konfigurieren, dass sie sich bei Google Cloud APIs wie der Compute Engine API oder der AI Platform API von Flotten mit einem gemischten Vertrauensmodell authentifizieren. Wenn Ihre Flotte ein gemeinsames Vertrauensmodell verwendet, lesen Sie den Artikel Authentifizierung bei Google Cloud APIs von Arbeitslasten in Flotten mit gemeinsamem Vertrauensmodell.

Diese Seite richtet sich an Plattformadministratoren und ‑operatoren sowie an Sicherheitsingenieure, die sich programmatisch von Flottenarbeitslasten bei Google Cloud APIs authentifizieren möchten. Weitere Informationen zu den Nutzerrollen und Beispielaufgaben, auf die wir in Google Cloud der 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 gemischtem Vertrauensmodell

Mit der Identitätsföderation von Arbeitslasten für Flotten können Sie IAM-Rollen für Google Cloud APIs und Ressourcen an Entitäten in Ihrer Flotte gewähren, z. B. an Arbeitslasten in einem bestimmten Namespace. 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. In Umgebungen mit gemischtem Vertrauensmodell wie Flotten mit mehreren Mandanten 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 IDs 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 Prinzipale in einem bestimmten Flotten-Namespace nicht versehentlich Zugriff auf andere Prinzipale gewährt wird, die mit der ID ü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 selbstverwalteter Workload Identity-Pools zur Bereitstellung von Identitäten für Arbeitslasten im Teambereich bietet folgende Vorteile:

  • Zugriffsgewährungen für Entitäten in Flotten-Namespaces gelten nicht versehentlich für Entitäten in anderen Namespaces oder Clustern.
  • 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.

Identitätsgleichheit in einer Umgebung mit gemischtem Vertrauensmodell

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 Teambereich finance-team und einen Flotten-Namespace finance-ns im Teambereich.
  • Sie binden den Cluster finance-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:

  • Sie werden im Flotten-Namespace finance-ns ausgeführt.
  • Sie verwenden das Dienstkonto finance-sa.

Wenn jedoch jemand im Cluster frontend-cluster einen Kubernetes-Namespace finance-ns und ein Dienstkonto finance-sa erstellt, erhält er dieselbe Identität wie die Arbeitslasten im Cluster finance-cluster. Das liegt daran, dass die gesamte Flotte den von Google verwalteten Workload Identity-Pool des Flotten-Hostprojekts verwendet und die Hauptkonto-ID keinen Hostcluster angibt.

Nehmen Sie die folgenden Änderungen am vorherigen Szenario vor:

  • Sie richten einen selbstverwalteten Workload Identity-Pool in Ihrer Flotte ein.
  • Sie konfigurieren den Cluster finance-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-Hostprojekts.

Diese Änderungen haben folgende Vorteile:

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

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 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 in Ihrer Flotte Funktionen zur Verwaltung von Flottenteams wie Teambereiche und Flotten-Namespaces verwenden. In der Anleitung auf dieser Seite wird gezeigt, wie Sie einen Beispielteambereich 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ür GKE-Cluster müssen Sie den Cluster in der Flotte registrieren.

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. Dieser Workload Identity-Pool ist der selbstverwaltete Pool.

  1. 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-Host Projekts.

  2. Gewähren Sie dem Flotten-Dienst-Agent die Rolle „IAM Workload Identity-Pooladministrator“ (roles/iam.workloadIdentityPoolAdmin) für den neuen Workload Identity Pool:

    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.

    Um das Sicherheitsprinzip der geringsten Berechtigung, zu befolgen, gewährt dieser Befehl die Rolle „IAM Workload Identity-Pooladministrator“ für den spezifischen Workload Identity-Pool, den Sie für die Flotte verwenden, und nicht für alle Workload Identity Pools im Projekt.

Selbstverwalteten Pool zur Flottenkonfiguration hinzufügen

In diesem Abschnitt aktivieren Sie selbstverwaltete Pools mit der Identitätsföderation von Arbeitslasten für Flotten und fügen den erstellten Pool der Flottenkonfiguration hinzu. In diesem Abschnitt finden Sie 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.

  1. Aktivieren Sie die Identitätsföderation von Arbeitslasten für Flotten auf Flottenebene:

    gcloud container fleet workload-identity enable \
  --project=FLEET_HOST_PROJECT_ID

    Ersetzen Sie FLEET_HOST_PROJECT_ID durch die Projekt-ID Ihres Flotten-Hostprojekts.

  2. Fügen Sie der Flottenkonfiguration den selbstverwalteten Workload Identity-Pool hinzu:

    gcloud 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

  3. 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 Ihres neuen Teambereichs.

  4. 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.

  5. 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 für Ihre neue Mitgliedschaftsbindung.
    • FLEET_CLUSTER_NAME: der Name des vorhandenen Flottenclusters, der an den Teambereich gebunden werden soll.

Workload Identity-Poolkonfiguration prüfen

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

  1. 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 eine Ressourcen-ID für Ihren Cluster.
    • scopeTenancyWorkloadIdentityPool: der Workload Identity-Pool, aus dem Arbeitslasten in Flotten-Namespaces innerhalb von Teambereichen IDs abrufen. 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 Flotten-Hostprojekts, aus dem standardmäßig alle anderen Arbeitslasten in der Flotte Identitäten abrufen.

  2. 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 abrufen, wie im nächsten Abschnitt beschrieben.

Arbeitslasten für Identitäten selbstverwaltete Pools verwenden lassen

Damit Arbeitslasten den selbstverwalteten Pool verwenden, konfigurieren Sie bestimmte Flotten-Namespaces in Flottenmitgliedsclustern mit einer Kubernetes-ConfigMap. Mit dieser Konfiguration pro Cluster und pro Namespace können Sie den Umfang der Zugriffsgewährungen von gesamten Flotten-Namespaces auf Arbeitslasten weiter reduzieren, die in bestimmten Flotten-Namespaces in bestimmten Clustern ausgeführt werden.

  1. Verbinden Sie sich mit Ihrem Flottenmitgliedscluster:

    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.

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

    gcloud iam workload-identity-pools describe POOL_NAME --location=global

    Die Ausgabe sieht etwa so aus:

    POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog

  3. 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

  4. 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:POOL_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.
    • POOL_NAME: der vollständige Name des selbstverwalteten Workload Identity-Pools aus der Ausgabe der vorherigen Schritte in diesem Abschnitt. Beispiel: projects/1234567890/locations/global/workloadIdentityPools/example-pool.
    • 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.

  5. Stellen Sie die ConfigMap in Ihrem Cluster bereit:

    kubectl create -f self-managed-pool.yaml

Durch die Bereitstellung 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 Flotten-Namespace und gewähren dem Dienstkonto eine IAM-Rolle. Pods, die dieses Dienstkonto verwenden, können dann auf die Google Cloud Ressourcen zugreifen, für die Sie die Rolle gewähren.

  1. Erstellen Sie ein Kubernetes-Dienstkonto in Ihrem Flotten-Namespace:

    kubectl create serviceaccount SERVICEACCOUNT_NAME \
    --namespace=NAMESPACE_NAME

    Ersetzen Sie Folgendes:

    • SERVICEACCOUNT_NAME: der Name Ihres neuen Dienstkontos.
    • NAMESPACE_NAME: der Name des Flotten-Namespace.

  2. Gewähren Sie dem Dienstkonto eine IAM-Rolle. Der folgende Beispielbefehl gewährt dem Dienstkonto die Rolle „Storage Object Viewer“ (roles/storage.objectViewer) für einen Bucket:

    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 Dienstkonto, das Sie erstellt haben. Die Anfragen, die Ihre Arbeitslasten an Google Cloud APIs senden, verwenden ein föderiertes Zugriffstoken. 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, können 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 APIs aufrufen Google Cloud müssen, sollten die folgenden Felder enthalten:

  • metadata.namespace: der Name des Flotten-Namespace.
  • spec.serviceAccountName: der Name des Kubernetes-Dienstkontos im Flotten-Namespace.
  • 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 Bearertoken für das Dienstkonto verwenden kann.
  • spec.volumes: ein projiziertes Volume, das ein Dienstkontotoken in den Pod einbindet. Die Zielgruppe des Tokens ist der selbstverwaltete Workload Identity-Pool. Die ConfigMap, die die Konfiguration der Identitätsföderation von Arbeitslasten für Flotten enthält, ist eine Quelle für das Volume.

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

Authentifizierung von einer 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 korrekt konfiguriert haben. Dazu listen Sie den Inhalt eines Beispiel-Cloud Storage-Bucket auf. Sie erstellen einen Bucket, gewähren einem Dienstkonto in einem Flotten-Namespace eine Rolle für den Bucket und stellen einen Pod bereit, um auf den Bucket zuzugreifen.

  1. 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

  2. Gewähren Sie dem Dienstkonto im Flotten-Namespace die Rolle roles/storage.objectViewer für den Bucket:

    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-Dienstkontos, das der Pod verwenden soll.

  3. 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
          expirationSeconds: 172800
      - configMap:
          name: google-application-credentials
          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-Dienstkontos, das der Pod verwenden soll.
    • POOL_NAME: der Name Ihres selbstverwalteten Workload Identity-Pools.

  4. Stellen Sie den Pod in Ihrem Cluster bereit:

    kubectl apply -f pod-bucket-access.yaml

  5. Öffnen Sie eine Shell-Sitzung im Pod:

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

  6. 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 annehmen können. Führen Sie in einem Cluster, der die Identitätsföderation von Arbeitslasten für Flotten verwendet, aber keine Flotten-Namespace- oder selbstverwaltete Poolkonfiguration hat, die folgenden Schritte aus:

  1. Erstellen Sie einen neuen Kubernetes-Namespace mit demselben Namen wie der Flotten-Namespace, in dem Sie den selbstverwalteten Workload Identity-Pool eingerichtet haben.
  2. Erstellen Sie ein neues Kubernetes-Dienstkonto mit demselben Namen wie das Dienstkonto, dem Sie in den vorherigen Abschnitten eine IAM-Rolle gewährt haben.

  3. Stellen Sie einen Pod bereit, der dasselbe Dienstkonto und denselben Namespace verwendet, für den aber im Feld spec.volumes.projected.sources.serviceAccountToken der von Google verwaltete Workload Identity-Pool angegeben ist. Dieser Pool hat die folgende Syntax:

    FLEET_HOST_PROJECT_ID.svc.id.goog

  4. Versuchen Sie, über eine Shell-Sitzung im Pod auf den Cloud Storage-Bucket zuzugreifen.

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

Nächste Schritte