Informationen zur 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ätsgleichheit für Arbeitslasten, die Funktionsweise der Identitätsföderation von Arbeitslasten für Flotten und Best Practices für die Verwaltung im großen Maßstab.

Diese Seite richtet sich an Plattformadministratoren und ‑operatoren sowie an Sicherheitsingenieure, die die Arbeitslastautorisierung im großen Maßstab effizienter verwalten 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:

Über föderierte Arbeitslastidentitäten in Google Cloud

Workload Identity-Föderation ist eine Google Cloud Funktion, mit der sich die Arbeitslasten in Ihren Clustern bei authentifizieren können, Google Cloud 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-Föderation für GKE ist eine GKE-spezifische Implementierung der Workload Identity-Föderation, die einen projektweiten, von Google verwalteten Workload Identity-Pool 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 befinden Google Cloud. Mit der Identitätsföderation von Arbeitslasten 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 APEs und anderen Diensten in Ihrer gesamten Flotte und sogar in mehreren Projekten konfigurieren.

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

Über 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 Workload Identity-Föderation 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 Clusterprojekt-ID ist.

Mit 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 befinden Google Cloud. Jeder Cluster in der Flotte verwendet den FLEET_HOST_PROJECT_ID.svc.id.goog Workload Identity Pool, wobei FLEET_HOST_PROJECT_ID die Projekt-ID des Flotten-Hostprojekts ist.

Wenn Sie Teambereiche, können Sie optional einen selbstverwalteten IAM-Workload Identity Pool für Cluster konfigurieren, der zusätzlich zum von Google verwalteten Pool verwendet werden soll. Dieser selbstverwaltete Pool bietet eine explizitere 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 bei Google 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 Flotten-Hostprojekts.

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

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

    • Selbstverwalteter Workload Identity-Pool (Vorschau): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, wobei POOL_HOST_PROJECT_NUMBER die Projekt nummer 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.

Über die 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-Föderation für GKE mit einem einzelnen Projekt gilt die Identitätsgleichheit für alle Entitäten, die in diesem Projekt eine Hauptkonto-ID gemeinsam nutzen. Bei der Identitätsföderation von Arbeitslasten für Flotten gilt diese Identitätsgleichheit jedoch implizit für alle Entitäten, die eine Hauptkonto-ID in der gesamten Flotte gemeinsam nutzen, unabhängig vom Clusterprojekt.

Nehmen wir beispielsweise eine Anwendung mit einem Back-End, das in mehreren Clustern in derselben Flotte bereitgestellt wird. Wenn Sie einer Hauptkonto-ID eine Rolle zuweisen, die das default-Kubernetes-Dienstkonto im backend-Kubernetes-Namespace auswählt, erhält jede Anwendung in diesem Namespace, die dieses Dienstkonto 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 Workload Identity-Föderation für GKE. Wenn Ihre Flotte jedoch Cluster enthält, die in anderen Projekten oder außerhalb von Google Cloudausgeführt werden, erstreckt sich diese implizite Identitätsgleichheit auf alle registrierten Cluster in der Flotte.

Identitätsgleichheit in Umgebungen mit mehreren Mandanten oder gemischter Vertrauenswürdigkeit

Standardmäßig verwendet Ihre Flotte den von Google verwalteten Workload Identity-Pool des Flotten-Hostprojekts, um Arbeitslasten in der gesamten Flotte Identitäten zuzuweisen. 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 gemischter Vertrauenswürdigkeit, in der diese eigenständigen Cluster Arbeitslasten mit einem anderen Vertrauensmodell ausführen, kann diese implizite Identitätsgleichheit zu unbeabsichtigtem Zugriff führen.

Mit Flotten können Sie dieses Modell mit mehreren Mandanten 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 innerhalb bestimmter Teambereiche 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 Flotten mit mehreren Mandanten verringern, indem Sie einen eigenen Workload Identity-Pool für bestimmte Cluster in Ihrer Flotte konfigurieren, der anstelle des von Google verwalteten Workload Identity-Pools verwendet werden soll. Dadurch unterscheiden sich die Hauptkonto-IDs für diese Arbeitslasten explizit von den Hauptkonto-IDs für eigenständige Cluster im Projekt. Diese explizite Identitätsgleichheit bietet Administratoren mehr Kontrolle über die Grenzen, innerhalb derer die Identitätsgleichheit gilt.

Das Modell der 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. Dadurch 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 nur Identitäten 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.

    Dadurch 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, bei dem dieselben Entitäten dieselben Anwendungen bereitstellen. Beispiel: Eine teamspezifische Flotte mit einem Cluster in jeder Region, in der eine replizierte Anwendung in jedem Cluster bereitgestellt wird.

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

  • Mehrere Vertrauensstufen in der Flotte: Sie führen Cluster mit mehreren Vertrauensstufen aus. Nehmen wir beispielsweise ein Szenario, in dem Finanzteams und Frontend-Teams Cluster in derselben Flotte haben. Mit einem selbstverwalteten Workload Identity-Pool können Sie die Zugriffsgewährungen für jedes Team nach Flotten-Namespace trennen. Das bedeutet, dass selbst der Clusteradministrator des Frontend-Clusters keine Identität im Flotten-Namespace erhalten kann, es sei denn, er hat explizite Berechtigungen.
  • Mehrere Vertrauensstufen im Projekt: In Ihrem Flotten-Hostprojekt werden eigenständige Cluster ausgeführt, die möglicherweise nicht dieselbe Vertrauensstufe wie Ihre Flotten cluster 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 auch unabhängig vom Flottenclusterprojekt. Wenn Sie einen selbstverwalteten Workload Identity-Pool für die Flotte festlegen, wird verhindert, dass Zugriffsgewährungen für den selbstverwalteten Pool unbeabsichtigt Zugriff auf die eigenständigen Cluster gewähren.
  • Best Practices für Teambereiche: Sie verwenden bereits Funktionen zur Flottenteamverwaltung und möchten empfohlene Best Practices für die Gewährung des Zugriffs auf Arbeitslasten implementieren. Wenn Sie einen selbstverwalteten Workload Identity-Pool festlegen, können Sie den Zugriff auf Arbeitslasten in einem bestimmten Flotten-Namespace in einem Teambereich 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ützten 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 die 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 bestimmte Google 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 Hauptkonto-ID der Arbeitslast verweist.
  3. ADC fügt das föderierte Zugriffstoken in die API-Anfrage ein.
  4. Die IAM-Zulassungsrichtlinie autorisiert die Hauptkonto-ID, 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