In diesem Dokument wird die Identitätsföderation von Arbeitslasten für GKE beschrieben. Es wird auch erläutert, wie sie funktioniert, wie sich die Aktivierung auf Ihre GKE-Cluster auswirkt und wie Sie Kubernetes-Entitäten in IAM-Richtlinien (Identity and Access Management) Rollen zuweisen. In den meisten Fällen ist die Identitätsföderation von Arbeitslasten für GKE die empfohlene Methode, um den Zugriff Ihrer Arbeitslasten, die in GKE ausgeführt werden, auf Google Cloud -Dienste zu schützen und zu verwalten.
Dieses Dokument richtet sich an Sicherheitsexperten und Operatoren, die Arbeitslasten in GKE verwalten, für die der Zugriff auf andere Google Cloud-Dienste erforderlich ist. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.
Terminologie
Auf dieser Seite 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 anGoogle 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 bestimmteGoogle 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.
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 Cloudausgeführt werden. Sie können die 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 verwaltetGoogle Cloud den Workload Identity-Pool und die relevanten Anbieter für Sie. Es ist kein externer Identitätsanbieter erforderlich.
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.googDer Workload Identity-Pool bietet ein Namensformat, mit dem IAM die Anmeldedaten des Kubernetes-Dienstkontos verstehen und als vertrauenswürdig einstufen kann. GKE löscht diesen Workload Identity-Pool nicht, auch wenn Sie alle Cluster in Ihrem Projekt löschen.
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.
Bedingungen in IAM-Richtlinien verwenden
Sie können den Umfang des Zugriffs auch einschränken, indem Sie Bedingungen in den Zulassungsrichtlinien festlegen. Bedingungen sind eine erweiterbare Methode, um festzulegen, wann eine Zulassungsrichtlinie angewendet werden soll. So können Sie beispielsweise mithilfe von Bedingungen vorübergehenden Zugriff auf eine Arbeitslast auf einer bestimmten Google Cloud -Ressource gewähren, sodass dieser Zugriff nicht manuell verwaltet werden muss.
Bedingungen können auch nützlich sein, wenn Sie Ihre Zulassungsrichtlinien auf Projekt-, Ordner- oder Organisationsebene festlegen, anstatt auf bestimmte Ressourcen wie Secret Manager-Secrets oder Cloud Storage-Buckets.
Wenn Sie Ihrer Zulassungsrichtlinie eine Bedingung hinzufügen möchten, verwenden Sie die folgenden Ressourcen:
- Bedingte Rollenbindungen verwalten: Bedingte Rollenbindungen hinzufügen, ändern oder entfernen.
- Temporären Zugriff konfigurieren: Mit Bedingungen können Sie in Zulassungsrichtlinien ablaufenden Zugriff auf Google Cloud -Ressourcen festlegen.
- Tags und bedingter Zugriff: Mit Bedingungen können Sie Zulassungsrichtlinien nur auf Ressourcen anwenden, die bestimmte Tags haben.
Die folgenden Beispielausdrücke sind für häufige Szenarien, in denen Sie Bedingungen verwenden könnten. Eine Liste der in Ausdrücken verfügbaren Attribute finden Sie unter Attributreferenz für IAM-Bedingungen.
| Beispiele für Bedingungsausdrücke | ||
|---|---|---|
| Zugriff vor der angegebenen Zeit zulassen | request.time < timestamp('Ersetzen Sie |
|
| Zugriff gewähren, wenn die Ressource in der Anfrage das angegebene Tag hat | resource.matchTag('Ersetzen Sie Folgendes:
|
|
Kubernetes-Ressourcen in IAM-Richtlinien referenzieren
In Ihrer IAM-Richtlinie verweisen Sie auf eine Kubernetes-Ressource, indem Sie eine IAM-Hauptkonto-ID verwenden, 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
In diesem Beispiel werden die folgenden Felder berücksichtigt:
PREFIX: muss 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 Prinzipaltypen 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:
Dienstkonto anhand der UID auswählen principal://iam.googleapis.com/projects/Ersetzen Sie Folgendes:
|
| Alle Pods in einem Namespace, unabhängig von Dienstkonto oder Cluster | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE 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 fordern 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. Die Anmeldung erfolgt über ein vom API-Server signiertes JSON Web Token (JWT).
- Der GKE-Metadatenserver verwendet Security Token Service, um das JWT gegen ein kurzlebiges föderiertes Zugriffstoken auszutauschen, das auf die Identität der Kubernetes-Arbeitslast verweist.
Das vom Security Token Service zurückgegebene föderierte Zugriffstoken kann Einschränkungen beim Zugriff auf einige Google Cloud -Dienste haben, wie unter Unterstützte Produkte und Einschränkungen beschrieben. Wenn der ausgewählte Google Cloud -Dienst Einschränkungen hat, können Sie optional die Identitätsübernahme des Dienstkontos konfigurieren. Diese Methode führt zu einem Zugriffstoken für ein IAM-Dienstkonto, mit dem Ihre Arbeitslast auf den Zieldienst zugreifen kann. Weitere Informationen finden Sie unter Kubernetes-ServiceAccounts mit IAM verknüpfen.
Die Arbeitslast kann dann auf alle Google Cloud APIs zugreifen, auf die die IAM-Hauptkonto-ID der Arbeitslast zugreifen kann.
Kontingent für die Exchange Token API im Security Token Service
Die Exchange Token API im Security Token Service hat ein Kontingentlimit von 6.000 Anfragen pro Minute. Wenn Sie QUOTA_EXCEEDED-Fehler erhalten, können Sie auf der Seite Kontingente und Systemlimits eine Erhöhung des Token exchange requests per minute-Kontingents anfordern.
Identitätsgleichheit
Wenn die Metadaten in Ihrer Hauptkonto-ID für Arbeitslasten in mehreren Clustern, die gemeinsam einen Workload Identity-Pool nutzen, gleich sind, weil sie zum selben Google Cloud -Projekt gehören, identifiziert IAM diese Arbeitslasten als dieselben. Wenn Sie beispielsweise denselben Namespace in zwei Clustern haben und Zugriff auf diesen Namespace in IAM 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. Cluster A und B 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.
Diese Identitätsgleichheit bedeutet auch, dass Sie jedem Cluster in einem bestimmten Workload Identity-Pool vertrauen können müssen. Wenn beispielsweise ein neuer Cluster, Cluster C im vorherigen Beispiel, einem nicht vertrauenswürdigen Team gehörte, kann es einen backend-Namespace erstellen und wie bei 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
Wenn Sie die Identitätsföderation von Arbeitslasten für GKE für einen Cluster aktivieren, werden die Metadaten jedes Knotens im Cluster 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.
Token-Lebensdauer
Standardmäßig hat das zurückgegebene Zugriffstoken eine Lebensdauer von 1 Stunde (3.600 Sekunden). Um die Clientlatenz zu verringern, werden die Zugriffstokens vom GKE-Metadatenserver im Cache gespeichert. In einigen Fällen kann es vorkommen, dass das vom Metadatenserver zurückgegebene gecachte Token kurz vor dem Ablauf steht.
Cloud-Clientbibliotheken haben eine integrierte Logik, die standardmäßig prüft, ob das Zugriffstoken in den nächsten 3 Minuten und 45 Sekunden abläuft. Wenn das Token innerhalb des Ablaufzeitraums liegt, wird es von GKE aktualisiert. Bei nachfolgenden API-Aufrufen kann das aktualisierte Token verwendet werden.
Wenn Sie mit Ihrem eigenen Code direkt auf Google Cloud APIs zugreifen, implementieren Sie eine ähnliche Logik, um den Ablauf von Tokens zu verarbeiten. Ihr Code sollte Folgendes tun:
- Prüfen Sie, ob das Zugriffstoken nach 3 Minuten und 45 Sekunden abläuft. Der Parameter
expin der Token-Nutzlast gibt den Zeitstempel für den Ablauf des Tokens an. - Wenn das Token in den nächsten 3 Minuten und 45 Sekunden abläuft, stellen Sie eine Tokenanfrage.
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/
| Eintrag | 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/
| Eintrag | 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. |
Die in der Tabelle aufgeführten Attribute sind die einzigen unterstützten Attribute. Wenn Sie versuchen, auf nicht unterstützte Attribute zuzugreifen, wird im gke-metadata-server-Pod im Namespace kube-system ein 404-Fehler generiert und protokolliert.
Der Fehler sieht etwa so aus:
HTTP/404: generic::not_found: no child "", Reason: "NOT_FOUND", UserMessage: "Not Found"
Wenn Sie istio-proxy verwenden, wird eine Fehlermeldung wie die folgende angezeigt:
Error fetching GCP Metadata property gcp_gce_instance_template: metadata: GCE metadata "instance/attributes/UNSUPPORTED_ATTRIBUTE" not defined
Projektmetadaten
Metadaten von Clusterprojekten werden im folgenden Verzeichnis gespeichert.
http://metadata.google.internal/computeMetadata/v1/project/
| Eintrag | 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 Sie Kubernetes-Dienstkonten mit IAM-Dienstkonten verknüpfen, um die Workload Identity-Föderation für GKE zu konfigurieren, gibt der GKE-Metadatenserver den Wert
SERVICEACCOUNT_NAME.svc.id.googals Dienstkonto-ID zurück. Diese Kennzeichnung verwendet nicht die standardmäßige IAM-Hauptkonto-ID-Syntax, was bei einigen programmatischen Vorgängen zu Fehlern führen kann. Wenn Sie die Dienstkonto-ID als IAM-Hauptkonto-ID abrufen möchten, fügen Sie Ihrem Kubernetes-ServiceAccount die Annotationiam.gke.io/return-principal-id-as-email: "true"hinzu.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.
Wenn Sie den Cloud Storage FUSE CSI-Treiber mit Standard-GKE-Clustern mit Version
1.33.3-gke.1226000oder höher verwenden, können sich die Pods, die im Hostnetzwerk (hostNetwork: true) ausgeführt werden, mit ihrem eigenen Kubernetes-Dienstkonto authentifizieren. Weitere Informationen finden Sie unter Zugriff für Pods mit Hostnetzwerk konfigurieren.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 500 gleichzeitigen Verbindungen zum GKE-Metadatenserver für jeden Knoten fest. Zusätzliche gleichzeitige Aufrufe, die dieses Limit überschreiten, werden in eine Warteschlange gestellt und später verarbeitet. Dieser Warteschlangenmechanismus kann zu
HTTP/499-Fehlern führen, wenn das Client-Zeitlimit erreicht wird, bevor der GKE-Metadatenserver die Anfrage verarbeiten kann.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.
Die Identitätsföderation von Arbeitslasten für GKE funktioniert innerhalb eines VPC Service Controls-Perimeters und ermöglicht den Zugriff auf Ressourcen darin. VPC Service Controls erzwingt jedoch keine Zugriffssteuerung für anbieterübergreifende Anfragen, die auf diesen föderierten Identitäten basieren. Sie können die Identität eines Dienstkontos übernehmen, um auf Ressourcen in einem anderen Perimeter zuzugreifen.
Alternativen zur Identitätsföderation von Arbeitslasten für GKE
Sie können eine der folgenden Alternativen zur Identitätsföderation von Arbeitslasten für GKE verwenden, um über GKE aufGoogle 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.
Dienstkontoschlüssel exportieren und als Kubernetes-Secrets speichern, die Sie als Volumes in Ihre Pods einbinden.
Nächste Schritte
- Identitätsföderation von Arbeitslasten für GKE aktivieren und konfigurieren
- Compute Engine-Metadatenserver
- Weitere Informationen zur Identitätsföderation von Arbeitslasten in anderen Umgebungen
- Unterstützung für die Identitätsföderation von Arbeitslasten für Cluster in Flotten mithilfe der Workload Identity der Flotte bereitstellen.