Workload Identity-Föderation 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.
Workload Identity-Föderation für GKE ist über IAM Workload Identity-Föderation 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 -Anbieter für Sie und erfordert keinen externen Identitätsanbieter.
- Weitere Informationen zur Workload Identity-Föderation in anderen Umgebungen finden Sie unter Workload Identity-Föderation.
- Informationen zum Aktivieren und Verwenden von Workload Identity-Föderation für GKE finden Sie unter Über GKE-Arbeitslasten auf Google Cloud APIs zugreifen.
- Um Workload Identity-Föderationsunterstützung für Cluster in Flotten bereitzustellen, verwenden Sie Flotten-Workload Identity.
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 Workload Identity-Föderation 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 Workload Identity-Föderation 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 von Workload Identity-Föderation für GKE
Wenn Sie Workload Identity-Föderation 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.googDer 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 mit Workload Identity-Föderation für GKE zu gewähren, erstellen Sie eine IAM-Zulassungsrichtlinie, die Zugriff auf eine bestimmte Google Cloud-Ressource einem Hauptkonto 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:
PREFIXmuss je nach ausgewählter RessourceprincipaloderprincipalSetsein.principalgilt für eine bestimmte Ressource, z. B. ein einzelnes Dienstkonto.principalSetgilt 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. Mitkubernetes.serviceaccount.uid/SERVICEACCOUNT_UIDwird 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/
Ersetzen Sie Folgendes:
Wählen Sie das Dienstkonto nach UID aus:
principal://iam.googleapis.com/projects/
Ersetzen Sie Folgendes:
|
| 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:
|
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:
- Standardanmeldedaten für Anwendungen fordert ein Google Cloud-Zugriffstoken vom Compute Engine-Metadatenserver an, der auf der VM ausgeführt wird.
- 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. Diese Anmeldedaten sind ein JSON Web Token (JWT), das von der Clusterzertifizierungsstelle signiert wurde.
- 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.
- 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, die gemeinsam einen Workload Identity-Pool nutzen, gleich sind, identifiziert IAM diese Arbeitslasten als dieselben. 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 Google Cloud-Projekt und daher 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.
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 Workload Identity-Föderation 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:
|
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 Workload Identity-Föderation 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.
Workload Identity-Föderation for GKE erfordert ein manuelles Einrichten von Cloud Run for Anthos, damit weiterhin Anfragemesswerte freigegeben werden können.
Workload Identity-Föderation 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 Workload Identity-Föderation 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.
Das Compute Engine-Standarddienstkonto Ihrer Knoten verwenden. Sie können Knotenpools als ein beliebiges IAM-Dienstkonto in Ihrem Projekt ausführen. Wenn Sie beim Erstellen des Knotenpools kein Dienstkonto angeben, verwendet GKE das Compute Engine-Standarddienstkonto für das Projekt. Das Compute Engine-Dienstkonto wird von allen auf diesem Knoten bereitgestellten Arbeitslasten gemeinsam genutzt. Dies kann zur Zuweisung übermäßiger Berechtigungen führen, was gegen das Prinzip der geringsten Berechtigung verstößt und für mehrmandantenfähige Cluster nicht angemessen ist.
Exportieren Sie Dienstkontoschlüssel und speichern Sie sie als Kubernetes-Secrets, die Sie in Ihren Pods als Volumes bereitstellen.