Workload Identity für Flotten verwenden

Anwendungen müssen sich bei der Verbindung zu anderen Diensten häufig authentifizieren (eine authentifizierbare Identität angeben). Beispielsweise müssen sich Ihre Anwendungen authentifizieren, um Google Cloud APIs wie die Compute Engine API oder die AI Platform API zu verwenden. Auf dieser Seite wird erläutert, wie Sie die Workload Identity der Flotte verwenden und wie sich Anwendungsarbeitslasten, die in einer Flotte gehostet werden, am besten und einfachsten bei Google Cloud APIs und Services authentifizieren.

Was ist die Workload Identity der Flotte?

Fleet Workload Identity erweitert die Funktionalität von GKE Workload Identity, mit der sich die Arbeitslasten in Ihrem Cluster bei Google authentifizieren können, ohne dass Sie Dienstkontoschlüssel für Google Cloud herunterladen, manuell rotieren und im Allgemeinen verwalten müssen. Stattdessen werden die Arbeitslasten mithilfe der vom Cluster generierten kurzlebigen Tokens authentifiziert. Alle Cluster mit aktivierter GKE Workload Identity verwenden den Workload Identity-Pool ihres Projekts, wenn IDs ausgestellt werden. Dadurch kann Identity and Access Management die Anmeldedaten von Kubernetes-Dienstkonten vertrauen und sie verstehen. Weitere Informationen zu GKE Workload Identity finden Sie unter Workload Identity verwenden.

Bei Flotten können registrierte Cluster den zusätzlichen Vorteil der Verwendung von fltet Workload Identity erhalten. Registrierte Cluster, für die Workload Identity aktiviert ist, können den flächendeckenden Flotten-Workload Identity-Pool verwenden, der die Authentifizierung bei Google APIs und anderen Diensten in Ihrer gesamten Flotte und in mehreren Projekten vereinfacht. Flotten Workload Identity kann auch von dem Connect-Agent auf einigen Clustertypen verwendet werden, um sich im Rahmen der Flotte-Mitgliedschaft bei Google zu authentifizieren. Außerdem ist es erforderlich, um einige projektübergreifende GKE Enterprise-Features wie Anthos Service Mesh zu nutzen.

Funktionsweise

Flotten verwenden die Workload Identity-Föderation, um jeder Anwendung eine eigene föderierte Identität zur Verfügung zu stellen, mit der sie sich bei Google Cloud und anderen von Ihnen entwickelten Diensten authentifizieren kann. Anwendungen, die in einer Flotte ausgeführt werden, erhalten eine föderierte Workload Identity im folgenden Format:

serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]

Wobei:

  • FLEET_PROJECT_ID.svc.id.goog ist eine Kurzdarstellung des Workload Identity-Pools für Ihre Flotte. Es gibt nur einen festen Workload Identity-Pool pro Flotte und dieser wird automatisch für Sie erstellt.
  • K8S_NAMESPACE ist der Kubernetes-Namespace, in dem das Kubernetes-Dienstkonto definiert ist.
  • KSA_NAME ist der Name des Kubernetes-Dienstkontos, das der Anwendung zugeordnet ist.

Alle Anwendungen, die in einer Flotte gehostet werden, haben denselben Workload Identity-Pool und bieten Anwendungen eine föderierte Identität, die abstrahiert, wo jede Anwendung gehostet wird. Dadurch können Sie einer Anwendung in einer Flotte generell statt Cluster für Cluster Zugriff auf eine Ressource (z. B. eine Google Cloud API) gewähren, selbst wenn die Anwendung in verschiedenen Google Cloud-Projekten oder Clouds bereitgestellt wird. Wie andere Features, die für eine Flotte aktiviert sind, basiert dies auf dem Flottenprinzip der Gleichheit. Dabei werden Kubernetes-Objekte mit demselben Namen in verschiedenen Clustern gleich behandelt. Beispiel: Wenn Sie eine Anwendung mit einem Backend haben, das in mehreren Clustern in derselben Flotte bereitgestellt wird und sich bei einer Google API authentifizieren muss, können Sie die Anwendung so konfigurieren, dass alle Dienste im "Backend"-Namespace auf diese API zugreifen können. Weitere Informationen zur Verwendung der Gleichheit, einschließlich der Identitätsgleichheit, finden Sie unter Funktionsweise von Flotten.

Cluster außerhalb von Google Cloud können auch Workload Identity verwenden, um eine Identität für den Connect-Agent zur Authentifizierung bei Google bereitzustellen. Weitere Informationen dazu, welche Clustertypen Workload Identity der Flotte verwenden, finden Sie unten im Abschnitt Clustereinrichtung.

Hinweis

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

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

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

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

Clustereinrichtung

Bevor Anwendungen in Ihrer Flotte eine Workload Identity 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 der Flotte konfiguriert werden. Die Vorgehensweise hängt dabei vom Clustertyp ab. Die meisten GKE-Cluster außerhalb von Google Cloud werden beim Erstellen automatisch für Ihre Projektflotte registriert. GKE-Cluster in Google Cloud und angehängten Clustern müssen manuell registriert werden.

Weitere Informationen zur Clusterkonfiguration finden Sie in der Dokumentation zum jeweiligen Clustertyp.

GKE

  1. Aktivieren Sie GKE Workload Identity, falls noch nicht aktiviert, in Ihrem Google Kubernetes Engine-Cluster.
  2. Folgen Sie der Anleitung zum Registrieren des Clusters mit Workload Identity.

GKE-Cluster außerhalb von Google Cloud

GKE on VMware, GKE on Bare Metal und Multi-Cloud-GKE-Cluster (sowohl in AWS als auch Azure) werden automatisch in Ihrer Projektflotte im Cluster registriert zur Cluster-Erstellungszeit. Ab GKE Enterprise 1.8 aktivieren alle diese Clustertypen Workload Identity der Flotte automatisch, wenn sie registriert sind. Vorhandene registrierte Cluster werden aktualisiert, um Workload Identity zu verwenden, wenn sie auf GKE Enterprise 1.8 oder höher aktualisiert werden.

Angehängte Cluster

EKS- und AKS-angehängte Cluster, die über die GKE Multi-Cloud API registriert sind, sind standardmäßig mit aktivierter Workload Identity der Flotte registriert. Andere Angehängte Cluster können mit aktivierter Workload Identity der Flotte aktiviert werden, wenn sie die erforderlichen Anforderungen erfüllen. Folgen Sie der Anleitung für Ihren Clustertyp unter Cluster registrieren.

Workload Identity für Flotten verwenden

Nachdem Sie Ihren Cluster registriert haben, können im Cluster bereitgestellte Arbeitslasten Workload Identities aus dem Workload Identity-Pool der Flotte verwenden. In diesem Abschnitt erfahren Sie, wie Sie mit der Workload Identity die Identität eines Google Cloud-Dienstkontos übernehmen, damit Ihre Arbeitslasten auf Google Cloud APIs zugreifen können. Das Agieren als Dienstkonto ist ein häufiger Anwendungsfall für föderierte Identitäten, da Sie damit Ihre Arbeitslasten bei jeder Google Cloud API authentifizieren können, auf die das Dienstkonto Zugriff hat, und Sie müssen sich dann nicht mehr mit der Wartung und Sicherheit befassen, indem Sie Dienstkontoschlüssel für jede Arbeitslast verwalten.

Identität eines Dienstkontos übernehmen

In diesem Abschnitt wird gezeigt, wie Sie die föderierte Workload Identity einer Anwendung so konfigurieren, dass sie die Identität eines Dienstkontos übernehmen kann. Zu diesem Zweck stellen Sie in einer ConfigMap die Datei mit den Standardanmeldedaten für Anwendungen bereit. Dazu gehört auch das Erstellen und Konfigurieren des Dienstkontos mit den entsprechenden Berechtigungen.

In diesem Beispiel werden die folgenden Platzhalterwerte verwendet:

  • WORKLOAD_IDENTITY_POOL ist der Workload Identity-Pool, der mit Ihrer Flotte verknüpft ist. Wie oben gezeigt, ist der Wert von WORKLOAD_IDENTITY_POOL FLEET_PROJECT_ID.svc.id.goog.
  • IDENTITY_PROVIDER ist der Name des Identitätsanbieters, der Ihrem Kubernetes-Cluster zugeordnet ist.
  • K8S_NAMESPACE ist der Kubernetes-Namespace, in dem das Kubernetes-Dienstkonto definiert ist.
  • KSA_NAME ist der Name des Kubernetes-Dienstkontos, das der Anwendung zugeordnet ist.
  • GSA_NAME ist der Name des Google-Dienstkontos, als das Ihre Anwendung agiert.
  • GSA_PROJECT_ID ist die Projekt-ID, für die das Google-Dienstkonto definiert ist.

So konfigurieren Sie die Workload Identity einer Flotte, um die Identität eines Dienstkontos zu übernehmen:

  1. Prüfen Sie, ob Ihr Cluster bei der Flotte registriert ist. Folgen Sie dazu den Schritten im Abschnitt Clustereinrichtung oben.

  2. Rufen Sie die Werte von WORKLOAD_IDENTITY_POOL und IDENTITY_PROVIDER für Ihren registrierten Cluster ab. Rufen Sie dazu die Flottenmitgliedschaftsdetails des Clusters mit dem folgenden Befehl ab. Ersetzen Sie MEMBERSHIP durch den eindeutigen Mitgliedschaftsnamen Ihres Clusters in der Flotte:

    gcloud container fleet memberships describe MEMBERSHIP

    Die Ausgabe beim Beschreiben der Mitgliedschaft (einige Felder wurden der Übersichtlichkeit halber ausgelassen) sieht so aus:

    authority:
 identityProvider: IDENTITY_PROVIDER
 workloadIdentityPool: WORKLOAD_IDENTITY_POOL
name: projects/FLEET_PROJECT_ID/locations/global/memberships/MEMBERSHIP

  3. Erstellen Sie ein Google Cloud-Dienstkonto, dessen Identität Ihre Anwendung bei der Authentifizierung bei Google verwenden kann, falls Sie noch keines haben:

    gcloud iam service-accounts create GSA_NAME --project=GSA_PROJECT_ID

    Das Dienstkonto muss sich nicht in Ihrem Flottenhostprojekt befinden. Sie können jedes Google Cloud-Dienstkonto in Ihrer Organisation verwenden. Weitere Informationen zu Dienstkonten und zu ihrer Funktionsweise finden Sie unter Dienstkonten.

  4. Prüfen Sie, ob Sie dem Dienstkonto alle erforderlichen Berechtigungen für den Zugriff auf Google Cloud APIs gewährt haben. Fügen Sie dazu die erforderlichen IAM-Richtlinienbindungen 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.

  5. Autorisieren Sie die Workload Identity Ihrer Anwendung, sich als das Dienstkonto auszugeben, indem Sie folgendermaßen eine IAM-Richtlinienbindung erstellen. Durch diese Bindung kann die föderierte Workload Identity Ihrer Anwendung als Google Cloud-Dienstkonto agieren.

    gcloud iam service-accounts add-iam-policy-binding \
  GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:WORKLOAD_IDENTITY_POOL[K8S_NAMESPACE/KSA_NAME]"

    Das Feld --member ist die Darstellung der föderierten Workload Identity Ihrer Anwendung in IAM.

  6. Erstellen Sie eine ConfigMap, die die Datei mit den Standardanmeldedaten für Anwendungen für Ihre Arbeitslast enthält. Diese Datei teilt der in Ihrer Arbeitslast kompilierten Clientbibliothek mit, wie sie sich bei Google authentifizieren kann. Die Datei mit den Standardanmeldedaten für Anwendungen enthält den relevanten Workload Identity-Pool, Informationen zu Dienstkonten und den Pfad zum projizierten Token, das im nächsten Schritt im Dateisystem des Containers bereitgestellt wird. GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com ist die E-Mail-Adresse des Dienstkontos, dessen Identität angenommen werden soll.

    Diese Konfiguration allein bietet keinen Zugriff zur Übernahme der Identität des Dienstkontos. Wenn auch die IAM-Bindung nicht vorhanden ist, kann der Pod das Dienstkonto nicht verwenden.

    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/GSA_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"
      }
    }

  7. Konfigurieren Sie Ihre Arbeitslast gemäß dem folgenden Beispiel. Die ConfigMap aus dem vorherigen Schritt wird in /var/run/secrets/tokens/gcp-ksa im Dateisystem des Containers zusammen mit einer prognostizierten Dienstkonto-Tokendatei als google-application-credentials.json bereitgestellt. Prognostizierte Tokens werden von Kubernetes ausgegeben und stellen die Identität der Arbeitslast innerhalb des Clusters dar. Diese Tokens werden von Cloud Clientbibliotheken automatisch mit Google ausgetauscht, um Tokens zu erhalten, die sich bei Google APIs authentifizieren können. Das Feld audience des projizierten Tokens muss auf den Wert WORKLOAD_IDENTITY_POOL gesetzt werden.

    kind: Namespace
apiVersion: v1
metadata:
  name:  K8S_NAMESPACE
---
kind: ServiceAccount
apiVersion: v1
metadata:
  namespace:  K8S_NAMESPACE
  name: KSA_NAME
automountServiceAccountToken: false
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace:  K8S_NAMESPACE
spec:
  serviceAccountName: KSA_NAME
  containers:
  - name: my-container
    image: my-image
    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"

Über Ihren Code authentifizieren

Cloud-Clientbibliotheken führen die Authentifizierung bei Google Cloud automatisch durch, wenn Sie sie verwenden, um über Ihren Code auf Google-Dienste zuzugreifen. Sie müssen Cloud-Clientbibliotheken verwenden, die Workload Identity-Föderation unterstützen, damit Sie die oben gezeigte Einrichtung in Ihren Anwendungen verwenden können. 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.