Über Workload Identity-Föderation für GKE

Identitätsföderation von Arbeitslasten für GKE wird für Arbeitslasten empfohlen, die in Google Kubernetes Engine (GKE) ausgeführt werden, um sicher und problemlos auf Google Cloud-Dienste zuzugreifen.

Die Identitätsföderation von Arbeitslasten für GKE ist über die IAM Identitätsföderation von Arbeitslasten verfügbar, die Identitäten für Arbeitslasten bereitstellt, die in Umgebungen innerhalb und außerhalb von Google Cloud ausgeführt werden. Sie können IAM Workload Identity-Föderation verwenden, um sich sicher bei unterstützten Google Cloud APIs von Arbeitslasten aus zu authentifizieren, die z. B. auf AWS, Azure und selbst verwalteten Kubernetes ausgeführt werden. In GKE verwaltet Google Cloud den Workload Identity-Pool und die relevanten Anbieter für Sie. Es ist kein externer Identitätsanbieter erforderlich.

Terminologie

In diesem Dokument wird zwischen Kubernetes-Dienstkonten und Identity and Access Management-Dienstkonten (IAM) unterschieden.

Kubernetes-Dienstkonten
Kubernetes-Ressourcen, die eine Identität für Prozesse bereitstellen, die in Ihren GKE-Pods ausgeführt werden
IAM-Dienstkonten
Google Cloud-Ressourcen, mit denen Anwendungen autorisierte Aufrufe an Google Cloud APIs ausführen können

Was ist die Identitätsföderation von Arbeitslasten für GKE?

In GKE ausgeführte Anwendungen benötigen möglicherweise Zugriff auf Google Cloud APIs wie die Compute Engine API, die BigQuery Storage API oder Machine Learning APIs.

Mit Workload Identity-Föderation für GKE können Sie IAM-Richtlinien verwenden, um Kubernetes-Arbeitslasten in Ihrem GKE-Cluster Zugriff auf bestimmte Google Cloud APIs zu gewähren, ohne dass eine manuelle Konfiguration oder weniger sichere Methoden wie Dienstkonto-Schlüsseldateien erforderlich sind. Mit Workload Identity-Föderation für GKE können Sie jeder Anwendung in Ihrem Cluster separate, detaillierte Identitäten und Autorisierungen zuweisen.

Dank der Identitätsföderation von Arbeitslasten für GKE muss keine Metadatenverbergung verwendet werden. Die vertraulichen Metadaten, die durch Metadatenverbergung geschützt werden, werden durch die Workload Identity-Föderation für GKE ebenfalls geschützt.

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

Wenn Sie die Identitätsföderation von Arbeitslasten für GKE in einem Cluster aktivieren, führt GKE Folgendes aus:

  • Erstellt einen festen Workload Identity-Pool für das Google Cloud-Projekt des Clusters im folgenden Format:

    PROJECT_ID.svc.id.goog

    Der Workload Identity-Pool bietet ein Namensformat, mit dem IAM die Anmeldedaten des Kubernetes-Dienstkontos verstehen und als vertrauenswürdig einstufen kann.

  • Registriert den GKE-Cluster als Identitätsanbieter im Workload Identity-Pool.

  • Stellt den GKE-Metadatenserver bereit, der Anmeldedatenanfragen von Arbeitslasten auf jedem Knoten abfängt.

IAM-Zulassungsrichtlinien für Google Cloud-Ressourcen erstellen

Um Zugriff über die Identitätsföderation von Arbeitslasten für GKE zu gewähren, erstellen Sie eine IAM-Zulassungsrichtlinie, die einem Hauptkonto Zugriff auf eine bestimmte Google Cloud-Ressource gewährt, das der Identität Ihrer Anwendung entspricht. Sie können beispielsweise allen Pods, die das Kubernetes-Dienstkonto database-reader verwenden, Leseberechtigungen für einen Cloud Storage-Bucket erteilen.

Eine Liste der Ressourcen, die Zulassungsrichtlinien unterstützen, finden Sie unter Ressourcentypen, die Zulassungsrichtlinien akzeptieren.

Sie können den Umfang des Zugriffs auch einschränken, indem Sie Bedingungen in den Zulassungsrichtlinien festlegen. Wenn Sie beispielsweise Pods, die das Dienstkonto database-reader im Cluster mysql verwenden, nur Lesezugriff auf einen Bucket gewähren möchten, können Sie diese Bedingung in Ihrer Zulassungsrichtlinie festlegen. Weitere Informationen zur Verwendung von Bedingungen in Zulassungsrichtlinien finden Sie unter Bedingte Rollenbindungen verwalten.

Kubernetes-Ressourcen in IAM-Richtlinien referenzieren

In Ihrer IAM-Richtlinie verweisen Sie mithilfe einer IAM-Hauptkonto-ID auf eine Kubernetes-Ressource, um die Ressource auszuwählen. Diese Kennzeichnung hat die folgende Syntax:

PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR

Betrachten Sie in diesem Beispiel die folgenden Felder:

  • PREFIX muss je nach ausgewählter Ressource principal oder principalSet sein. principal gilt für eine bestimmte Ressource, z. B. ein einzelnes Dienstkonto. principalSet gilt für mehrere Ressourcen, die zur angegebenen Ressource gehören, wie z. B. alle Pods in einem bestimmten Cluster.
  • SELECTOR: ein String, der einen Hauptkontotyp auswählt. Mit kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID wird beispielsweise ein Dienstkonto anhand seiner UID ausgewählt.

In der folgenden Tabelle sind die unterstützten Hauptkontotypen in GKE aufgeführt:

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. Die Projektnummer finden Sie unter Projekte identifizieren.
  • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
  • NAMESPACE: der Kubernetes-Namespace
  • SERVICEACCOUNT: Der Name des Kubernetes-Dienstkontos.
Wählen Sie das Dienstkonto nach UID aus: 
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. Die Projektnummer finden Sie unter Projekte identifizieren.
  • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
  • SERVICEACCOUNT_UID: die UID des Objekts ServiceAccount auf dem API-Server.
Alle Pods in einem bestimmten Cluster 
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME

Ersetzen Sie Folgendes:

  • PROJECT_NUMBER: Ihre numerische Projektnummer. Die Projektnummer finden Sie unter Projekte identifizieren.
  • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
  • CLUSTER_NAME: Name Ihres GKE-Clusters.
  • LOCATION: Der Standort Ihres Clusters.

Anmeldedatenfluss

Wenn eine Arbeitslast eine Anfrage zum Zugriff auf eine Google Cloud API sendet, z. B. bei Verwendung einer Google Cloud-Clientbibliothek, werden folgende Authentifizierungsschritte ausgeführt:

Wie eine Arbeitslast ein IAM-Dienstkonto-Token mit Workload Identity abruft.
Abbildung 1: Wie eine Arbeitslast ein föderiertes Identitätstoken über die Identitätsföderation von Arbeitslasten für GKE abruft.
  1. Standardanmeldedaten für Anwendungen fordert ein Google Cloud-Zugriffstoken vom Compute Engine-Metadatenserver an, der auf der VM ausgeführt wird.
  2. Der GKE-Metadatenserver fängt die Tokenanfrage ab und fragt den Kubernetes API-Server nach einem Kubernetes-Dienstkonto-Token, mit dem die anfragende Arbeitslast identifiziert wird. Die Anmeldung erfolgt über ein vom API-Server signiertes JSON Web Token (JWT).
  3. Der GKE-Metadatenserver verwendet Security Token Service, um das JWT gegen ein kurzlebiges föderiertes Google Cloud-Zugriffstoken auszutauschen, das auf die Identität der Kubernetes-Arbeitslast verweist.
  4. Der GKE-Metadatenserver stellt das föderierte Zugriffstoken für die Arbeitslast bereit.

Die Arbeitslast kann dann auf alle Google Cloud APIs zugreifen, auf die die IAM-Hauptkonto-ID der Arbeitslast zugreifen kann.

Identitätsgleichheit

Wenn die Metadaten in Ihrer Hauptkonto-ID für Arbeitslasten in mehreren Clustern identisch sind, die einen Workload Identity-Pool teilen, da sie zum selben Google Cloud-Projekt gehören, identifiziert IAM diese Arbeitslasten als identisch. Wenn Sie beispielsweise denselben Namespace in zwei Clustern haben und in IAM Zugriff auf diesen Namespace gewähren, erhalten die Arbeitslasten in diesem Namespace in beiden Clustern diesen Zugriff. Sie können diesen Zugriff auf bestimmte Cluster mithilfe von bedingten IAM-Richtlinien beschränken.

Betrachten Sie beispielsweise das folgende Diagramm. Die Cluster A, B und C gehören zum selben Workload Identity-Pool. Google Cloud identifiziert Anwendungen, die das Dienstkonto back-ksa im Namespace backend von Cluster A und Cluster B verwenden, als dieselbe Identität. IAM unterscheidet nicht zwischen den Clustern, die die Aufrufe ausführen.

Diagramm zur Identitätsgleichheit in einem Workload Identity-Arbeitspool
Abbildung 2: Identitätsgleichheit beim Zugriff auf Google Cloud APIs mit der Identitätsföderation von Arbeitslasten für GKE.

Diese Identitätsgleichheit bedeutet auch, dass Sie jedem Cluster in einem bestimmten Workload Identity-Pool vertrauen können müssen. Wenn beispielsweise Cluster C im vorherigen Beispiel einem nicht vertrauenswürdigen Team gehörte, kann er einen backend-Namespace erstellen und wie Cluster A und Cluster B über das Dienstkonto back-ksa auf Google Cloud APIs zugreifen.

Um einen nicht vertrauenswürdigen Zugriff zu vermeiden, platzieren Sie Ihre Cluster in separaten Projekten, damit sie unterschiedliche Workload Identity-Pools erhalten, oder achten Sie darauf, dass die Namespace-Namen voneinander verschieden sind, um eine gemeinsame Hauptkonto-ID zu vermeiden.

GKE-Metadatenserver

Die Metadaten jedes Knotens in GKE mit aktivierter Identitätsföderation von Arbeitslasten für GKE werden auf dem GKE-Metadatenserver gespeichert. Der GKE-Metadatenserver ist eine Teilmenge der Compute Engine-Metadatenserver-Endpunkte, die für Kubernetes-Arbeitslasten erforderlich sind.

Der GKE-Metadatenserver wird als DaemonSet mit einem Pod auf jedem Linux-Knoten oder einem nativen Windows-Dienst auf jedem Windows-Knoten im Cluster ausgeführt. Der Metadatenserver fängt HTTP-Anfragen an http://metadata.google.internal (169.254.169.254:80) ab. Mit der Anfrage GET /computeMetadata/v1/instance/service-accounts/default/token wird beispielsweise ein Token für das IAM-Dienstkonto abgerufen, dessen Identität der Pod annehmen soll. Der Traffic zum GKE-Metadatenserver verlässt nie die VM-Instanz, die den Pod hostet.

In den folgenden Tabellen wird die Teilmenge der auf dem GKE-Metadatenserver verfügbaren Compute Engine-Metadatenserver-Endpunkte beschrieben. Eine vollständige Liste der auf dem Compute Engine-Metadatenserver verfügbaren Endpunkte finden Sie unter Standardmäßige VM-Metadatenwerte.

Instanzmetadaten

Metadaten der Instanzen werden im folgenden Verzeichnis gespeichert.

http://metadata.google.internal/computeMetadata/v1/instance/

Entry Beschreibung
hostname

Der Hostname Ihres Knotens.
id

Die eindeutige ID Ihres Knotens.
service-accounts/

Ein Verzeichnis mit Dienstkonten, die mit diesem Knoten verknüpft sind. Für jedes Dienstkonto sind folgende Informationen verfügbar:

  • aliases
  • email: Die E-Mail-Adresse des Dienstkontos.
  • identity: Ein JSON-Webtoken (JWT), das für den Knoten eindeutig ist. Sie müssen in Ihrer Anfrage den Parameter audience angeben. Beispiel: ?audience=http://www.example.com
  • scopes: Die Zugriffsbereiche, die dem Dienstkonto zugewiesen sind.
  • token: Das OAuth 2.0-Zugriffstoken zur Authentifizierung Ihrer Arbeitslasten.
zone

Die Compute Engine-Zone Ihres GKE-Knotens.

Instanzattribute

Instanzattribute werden im folgenden Verzeichnis gespeichert:

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

Entry Beschreibung
cluster-location

Die Compute Engine-Zone oder -Region Ihres Clusters.
cluster-name

Der Name Ihres GKE-Clusters.
cluster-uid

Die UID Ihres GKE-Clusters.

Projektmetadaten

Metadaten von Clusterprojekten werden im folgenden Verzeichnis gespeichert.

http://metadata.google.internal/computeMetadata/v1/project/

Entry Beschreibung
project-id

Ihre Google Cloud-Projekt-ID.
numeric-project-id

Ihre Google Cloud-Projektnummer.

Einschränkungen der Identitätsföderation von Arbeitslasten für GKE

  • Sie können den Namen des Workload Identity-Pools, den GKE für Ihr Google Cloud-Projekt erstellt, nicht ändern.

  • Wenn GKE den GKE-Metadatenserver in einem Knotenpool aktiviert, können Pods nicht mehr auf den Compute Engine-Metadatenserver zugreifen. Stattdessen fängt der GKE-Metadatenserver Anfragen von diesen Pods an Metadatenendpunkte ab, mit Ausnahme von Pods, die im Hostnetzwerk ausgeführt werden.

  • Es dauert einige Sekunden, bis der GKE-Metadatenserver Anfragen für einen neu erstellten Pod akzeptiert. Daher können Versuche, sich mit Workload Identity-Föderation für GKE innerhalb der ersten Sekunden eines Pods zu authentifizieren, fehlschlagen. Wiederholen Sie den Aufruf, um das Problem zu beheben. Weitere Informationen finden Sie unter Fehlerbehebung.

  • In GKE integrierte Logging- und Monitoring-Agents verwenden weiterhin das Dienstkonto des Knotens.

  • Die Identitätsföderation von Arbeitslasten for GKE erfordert ein manuelles Einrichten des Knative Serving, um weiterhin Anfragemesswerte zur Verfügung zu stellen.

  • Die Identitätsföderation von Arbeitslasten für GKE legt ein Limit von 200 Verbindungen zum GKE-Metadatenserver für jeden Knoten fest, um Arbeitsspeicherprobleme zu vermeiden. Wenn Ihre Knoten dieses Limit überschreiten, können Zeitüberschreitungen auftreten.

  • Workload Identity-Föderation für GKE für Windows Server-Knoten ist in den GKE-Versionen 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 und höher verfügbar.

  • Der GKE-Metadatenserver verwendet Arbeitsspeicherressourcen, die proportional zur Gesamtzahl der Kubernetes-Dienstkonten in Ihrem Cluster sind. Wenn Ihr Cluster mehr als 3.000 Kubernetes-Dienstkonten hat, beendet das Kubelet möglicherweise die Metadatenserver-Pods. Informationen zur Problemminderung finden Sie unter Fehlerbehebung.

Alternativen zur Identitätsföderation von Arbeitslasten für GKE

Sie können eine der folgenden Alternativen zu Workload Identity-Föderation for GKE verwenden, um über GKE auf Google Cloud APIs zuzugreifen. Wir empfehlen die Verwendung von Workload Identity-Föderation für GKE, da Sie für diese Alternativen bestimmte Sicherheitskompromisse eingehen müssen.

Nächste Schritte