Identitätsföderation von Arbeitslasten für Flotten

Auf dieser Seite wird die Identitätsföderation von Arbeitslasten für Flotten beschrieben. Dies ist ein Mechanismus zum Authentifizieren von Anfragen von Flottenarbeitslasten an Google Cloud APIs. Auf dieser Seite erfahren Sie mehr über die Identität von Workloads, die Funktionsweise der Workload Identity-Föderation für Flotten und Best Practices für die Verwaltung im großen Maßstab.

Diese Seite richtet sich an Plattformadministratoren und ‑betreiber sowie an Sicherheitsexperten, die die Autorisierung von Arbeitslasten effizienter im großen Maßstab verwalten 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:

Föderierte Arbeitslastidentitäten in Google Cloud

Die Workload Identity-Föderation ist eine Google Cloud Funktion, mit der sich die Arbeitslasten in Ihren Clustern bei Google Cloud authentifizieren können, ohne dass Sie Anmeldedaten herunterladen, manuell rotieren und im Allgemeinen verwalten müssen. Stattdessen werden die Arbeitslasten mithilfe der von Google Cloudgenerierten kurzlebigen Tokens authentifiziert.

Die Workload Identity Federation for GKE ist eine GKE-spezifische Implementierung der Workload Identity Federation, die einen projektweiten, von Google verwalteten Pool mit Arbeitslastidentitäten bietet, 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 Cloudbefinden. Mit der Workload Identity-Föderation für Flotten erhalten registrierte Cluster, für die die Workload Identity-Föderation für die Flottenmitgliedschaft aktiviert ist, Identitäten über einen flottenweiten, von Google verwalteten Workload Identity-Pool. Mit diesem freigegebenen Pool können Sie die Authentifizierung bei Google Cloud APIs und anderen Diensten in Ihrer gesamten Flotte und sogar in mehreren Projekten konfigurieren.

Die Workload Identity-Föderation für Flotten kann auch vom Connect-Agent auf einigen Clustertypen verwendet werden, um sich im Rahmen der Flottenmitgliedschaft bei Google Cloud zu authentifizieren. Außerdem ist sie erforderlich, um einige projektübergreifende GKE-Features wie Cloud Service Mesh zu nutzen.

Workload Identity-Pools

Ein Workload Identity-Pool ist eine Entität, mit der Identitäten für Ihre Anwendungen zentral verwaltet werden. Wenn Sie die Identitätsföderation von Arbeitslasten für GKE in Ihren Clustern aktivieren, erhält das Clusterprojekt einen von Google verwalteten Workload Identity-Pool mit einem festen, projektspezifischen Namen. Anwendungen in Ihren Clustern erhalten Identitäten aus dem von Google verwalteten Workload Identity-Pool, um Google Cloud API-Aufrufe zu authentifizieren. Der von Google verwaltete Workload Identity-Pool hat die Syntax PROJECT_ID.svc.id.goog, wobei PROJECT_ID die Cluster-Projekt-ID ist.

Bei der Identitätsföderation von Arbeitslasten für Flotten ist der von Google verwaltete Workload Identity-Pool des Flotten-Hostprojekts auch der Workload Identity-Pool für alle Cluster, die Sie in der Flotte registrieren, unabhängig davon, ob sich diese Cluster in anderen Projekten oder außerhalb von Google Cloudbefinden. Jeder Cluster in der Flotte verwendet den Workload Identity-Pool FLEET_HOST_PROJECT_ID.svc.id.goog, wobei FLEET_HOST_PROJECT_ID die Projekt-ID des Flotten-Hostprojekts ist.

Wenn Sie Teambereiche verwenden, können Sie optional einen selbstverwalteten IAM-Workload Identity-Pool für Cluster konfigurieren, der zusätzlich zum von Google verwalteten Pool verwendet wird. Dieser selbstverwaltete Pool bietet mehr Kontrolle darüber, welche Arbeitslasten bestimmte Identitäten erhalten.

Jede Anwendung in Ihrer Flotte erhält eine eindeutige föderierte Identität aus dem Workload Identity-Pool der Flotte, mit der sich die Anwendung beiGoogle 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/WORKLOAD_IDENTITY_POOL_NAME/SELECTOR

Diese Syntax hat die folgenden Felder:

  • PREFIX: principal oder principalSet, je nach dem Typ der Kubernetes-Ressource, die Sie im Feld SELECTOR auswählen.
  • FLEET_PROJECT_NUMBER: die Projektnummer des Hostprojekts der Flotte.

  • WORKLOAD_IDENTITY_POOL_NAME: den Workload Identity-Pool für Ihre Flotte. Dieser Wert hängt vom Workload Identity-Pool ab, den Sie in jedem Cluster einrichten:

    • Von Google verwalteter Workload Identity-Pool: FLEET_HOST_PROJECT_ID.svc.id.goog

    • Selbstverwalteter Workload Identity-Pool (Vorabversion): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, wobei POOL_HOST_PROJECT_NUMBER die Projektnummer des Projekts ist, in dem Sie den selbstverwalteten Workload Identity-Pool erstellt haben.

  • SELECTOR: die Ressourcenauswahl. Eine Liste der unterstützten Auswahl finden Sie im Abschnitt Unterstützte Hauptkonto-IDs. Mit subject/ns/NAMESPACE/sa/SERVICEACCOUNT wird beispielsweise ein bestimmtes Kubernetes-Dienstkonto in einem bestimmten Namespace ausgewählt.

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.

Identitätsgleichheit

Wie andere für eine Flotte aktivierte Funktionen basiert die Identitätsföderation von Arbeitslasten für Flotten auf dem Prinzip der Gleichheit. Dabei werden Kubernetes-Objekte mit demselben Namen und Namespace in verschiedenen Clustern gleich behandelt. Weitere Informationen zum allgemeinen Prinzip der Gleichheit in Flotten finden Sie unter Gleichheit.

Bei der Workload Identity Federation for GKE mit einem einzelnen Projekt gilt die Identitätsgleichheit für alle Entitäten, die in diesem Projekt eine gemeinsame Hauptkonto-ID haben. Bei der Identitätsföderation von Arbeitslasten für Flotten gilt diese Identität jedoch implizit für alle Entitäten, die sich eine Hauptkonto-ID in der gesamten Flotte teilen, unabhängig vom Clusterprojekt.

Stellen Sie sich beispielsweise eine Anwendung mit einem Back-End vor, das in mehreren Clustern in derselben Flotte bereitgestellt wird. Wenn Sie einem Hauptkonto eine Rolle zuweisen, die das Kubernetes-ServiceAccount default im Kubernetes-Namespace backend auswählt, erhält jede Anwendung in diesem Namespace, die dieses ServiceAccount verwendet, denselben Zugriff.

Wenn in Ihrer Flotte nur Cluster im Flotten-Hostprojekt ausgeführt werden, sind die Auswirkungen der Identitätsgleichheit dieselben wie bei der Identitätsföderation von Arbeitslasten für GKE. Wenn Ihre Flotte jedoch Cluster enthält, die in anderen Projekten oder außerhalb vonGoogle Cloudausgeführt werden, erstreckt sich diese implizite Identität auf alle registrierten Cluster in der Flotte.

Identitätsgleichheit in Mehrmandanten- oder Umgebungen mit unterschiedlichen Vertrauensstufen

Standardmäßig verwendet Ihre Flotte den von Google verwalteten Workload Identity-Pool des Flotten-Hostprojekts, um Arbeitslasten in der gesamten Flotte Identitäten bereitzustellen. Alle Cluster im Flotten-Hostprojekt, einschließlich eigenständiger Cluster, die nicht in der Flotte registriert sind, verwenden diesen Workload Identity-Pool. In einer Umgebung mit unterschiedlichen Vertrauensstufen, in der auf diesen eigenständigen Clustern Arbeitslasten mit einem anderen Vertrauensmodell ausgeführt werden, kann diese implizite Identitätsgleichheit zu unbeabsichtigtem Zugriff führen.

Mit Flotten können Sie dieses Multi-Tenant-Modell mithilfe von Teambereichen und Flotten-Namespaces verwalten. Mit Teambereichen können Sie Teilmengen von Flottenressourcen wie Cluster für die Verwendung durch bestimmte Teams in Ihrer Organisation festlegen. Mit Flotten-Namespaces können Sie Kubernetes-Namespaces in bestimmten Teambereichen definieren, sodass bestimmte Teams Arbeitslasten nur in den Namespaces in ihrem Teambereich ausführen können. Weitere Informationen finden Sie unter Flottenteamverwaltung – Übersicht.

Wenn Sie Teambereiche verwenden, können Sie die Komplexität der Identitätsgleichheit in Multi-Tenant-Flotten verringern, indem Sie Ihren eigenen Workload Identity-Pool für bestimmte Cluster in Ihrer Flotte konfigurieren, der anstelle des von Google verwalteten Workload Identity-Pools verwendet werden soll. Daher unterscheiden sich die Hauptkonto-IDs für diese Arbeitslasten explizit von den Hauptkonto-IDs für eigenständige Cluster im Projekt. Mit dieser expliziten Identitätsgleichheit haben Administratoren mehr Kontrolle über die Grenzen, innerhalb derer die Identitätsgleichheit gilt.

Das Modell für die Identitätsgleichheit in Ihrer Flotte ändert sich je nachdem, ob Sie nur den von Google verwalteten Workload Identity-Pool verwenden oder einen selbstverwalteten Workload Identity-Pool konfigurieren:

  • Implizite Identitätsgleichheit: Alle Arbeitslasten in einer Flotte verwenden den von Google verwalteten Workload Identity-Pool. Daher haben alle Arbeitslasten, die dieselbe Hauptkonto-ID verwenden, implizit denselben Zugriff.

  • Explizite Identitätsgleichheit (Vorschau): Sie konfigurieren einen selbstverwalteten Workload Identity-Pool für Teambereiche in der Flotte. Der selbstverwaltete Pool stellt Identitäten nur für Arbeitslasten bereit, wenn Sie einen Cluster so konfigurieren, dass er den selbstverwalteten Pool für einen bestimmten Flotten-Namespace verwendet. Arbeitslasten, die in anderen Kubernetes-Namespaces und -Clustern ausgeführt werden, können den selbstverwalteten Pool nicht verwenden.

    Daher unterscheidet sich die Identitätsgleichheit von Arbeitslasten, die den selbstverwalteten Pool verwenden, von der Identitätsgleichheit von Arbeitslasten, die nur den von Google verwalteten Workload Identity-Pool verwenden können.

Wann sollten selbstverwaltete Workload Identity-Pools verwendet werden?

Verwenden Sie den von Google verwalteten Workload Identity-Pool, wenn jeder Cluster ein ähnliches Vertrauensniveau hat, in dem dieselben Entitäten dieselben Anwendungen bereitstellen. Ein Beispiel ist eine teamspezifische Flotte mit einem Cluster in jeder Region, in dem eine replizierte Anwendung bereitgestellt wird.

Wir empfehlen, einen selbstverwalteten Workload Identity-Pool für Ihre Flotte in den folgenden Szenarien zu konfigurieren:

  • Mehrere Vertrauensebenen in der Flotte: Sie führen Cluster mit mehreren Vertrauensebenen aus. Nehmen wir beispielsweise an, dass Finanzteams und Frontend-Teams Cluster in derselben Flotte haben. Mit einem selbstverwalteten Workload Identity-Pool können Sie die Zugriffsberechtigungen für jedes Team nach Flottennamespace trennen. Das bedeutet, dass selbst der Clusteradministrator des Frontend-Clusters keine Identität im Flottennamespace erhalten kann, sofern er nicht über explizite Berechtigungen verfügt.
  • Mehrere Vertrauensstufen im Projekt: In Ihrem Flotten-Hostprojekt werden eigenständige Cluster ausgeführt, die möglicherweise nicht dieselbe Vertrauensstufe wie Ihre Flottencluster haben. Standardmäßig verwenden diese eigenständigen Cluster den von Google verwalteten Workload Identity-Pool des Flotten-Hostprojekts. Ihre Flottencluster verwenden diesen Workload Identity-Pool ebenfalls, unabhängig vom Flottenclusterprojekt. Wenn Sie einen selbstverwalteten Workload Identity-Pool für die Flotte festlegen, wird sichergestellt, dass durch Zugriffsgewährungen für den selbstverwalteten Pool nicht versehentlich Zugriff auf die eigenständigen Cluster gewährt wird.
  • Best Practices für Teambereiche: Sie verwenden bereits Funktionen zur Flottenteamverwaltung und möchten die empfohlenen Best Practices für die Gewährung des Zugriffs auf Arbeitslasten implementieren. Wenn Sie einen selbstverwalteten Workload Identity-Pool festlegen, können Sie Arbeitslasten in einem bestimmten Flotten-Namespace in einem Teambereich Zugriff gewähren, ohne diesen Zugriff auf andere Teambereiche zu gewähren, in denen Arbeitslasten in denselben Clustern ausgeführt werden.

Funktionsweise der Identitätsföderation von Arbeitslasten für Flotten

In den folgenden Abschnitten wird beschrieben, wie die Identitätsföderation von Arbeitslasten für Flotten funktioniert, einschließlich des Ablaufs von Authentifizierungsanmeldedaten und unterstützter IAM-Hauptkonto-IDs.

Anmeldedatenfluss

So können Sie Anwendungen in einem bestimmten Namespace mithilfe der Workload Identity-Föderation der Flotte authentifizieren:

  1. Stellen Sie in diesem Namespace eine ConfigMap mit den folgenden Informationen bereit:

    • den Workload Identity-Pool und den Identitätsanbieter für Ihren Cluster.
    • den Pfad in jedem Pod, auf dem Kubernetes ein ServiceAccount-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.

  2. Erstellen Sie eine IAM-Zulassungsrichtlinie, die der Hauptkonto-ID des Hauptkontos in Ihren Clustern Zugriff auf bestimmteGoogle Cloud -Ressourcen gewährt, z. B. einem Dienstkonto im Namespace.

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

Wenn die Arbeitslast einen Google Cloud API-Aufruf ausführt, geschieht Folgendes:

  1. 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.
  2. 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 Zugriffstoken von Security Token Service auszutauschen, das auf die Haupt-ID der Arbeitslast verweist.
  3. ADC fügt das föderierte Zugriffstoken in die API-Anfrage ein.
  4. Die IAM-Zulassungsrichtlinie autorisiert die Identität des Hauptkontos, die angeforderte Aktion auf der Google Cloud -Ressource auszuführen.

Unterstützte Hauptkonto-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/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Ersetzen Sie Folgendes:

  • PROJECT_NUMBER: Ihre numerische Projektnummer. Informationen zum Ermitteln der Projektnummer finden Sie unter Projekte identifizieren.
  • PROJECT_ID: Ihre Google Cloud -Projekt-ID
  • NAMESPACE: der Kubernetes-Namespace
  • SERVICEACCOUNT: Der Name des Kubernetes-Dienstkontos.
Dienstkonto anhand der UID auswählen 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Ersetzen Sie Folgendes:

  • PROJECT_NUMBER: Ihre numerische Projektnummer. Informationen zum Ermitteln der Projektnummer finden Sie unter Projekte identifizieren.
  • PROJECT_ID: Ihre Flottenprojekt-ID.
  • SERVICEACCOUNT_UID: die UID des ServiceAccount-Objekts auf dem API-Server.

Nächste Schritte