Workload Identity

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Workload Identity wird für Ihre Arbeitslasten empfohlen, die in Google Kubernetes Engine (GKE) ausgeführt werden, um sicher und problemlos auf Google Cloud-Dienste zuzugreifen.

Weitere Informationen zum Aktivieren und Verwenden von Workload Identity in GKE finden Sie unter Workload Identity verwenden.

Sie können eine Flotten-Workload Identity verwenden, um Workload Identity-Föderationsunterstützung für Cluster bereitzustellen, die in Flotten registriert sind, einschließlich Anthos-Clustern.

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 Workload Identity?

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.

Workload Identity ermöglicht einem Kubernetes-Dienstkonto in Ihrem GKE-Cluster, als IAM-Dienstkonto zu fungieren. Pods, die das konfigurierte Kubernetes-Dienstkonto verwenden, werden beim Zugriff auf Google Cloud APIs automatisch als IAM-Dienstkonto authentifiziert. Mit Workload Identity können Sie jeder Anwendung in Ihrem Cluster separate, detaillierte Identitäten und Autorisierungen zuweisen.

Funktionsweise von Workload Identity

Wenn Sie Workload Identity für einen Cluster aktivieren, erstellt GKE automatisch 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 von Kubernetes-Dienstkonten verstehen und als vertrauenswürdig einstufen kann. Durch die Aktivierung von Workload Identity werden Ihren Arbeitslasten standardmäßig keine IAM-Berechtigungen erteilt.

Wenn Sie ein Kubernetes-Dienstkonto in einem Namespace für die Verwendung von Workload Identity konfigurieren, authentifiziert IAM die Anmeldedaten mit dem folgenden Mitgliedsnamen:

serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KUBERNETES_SERVICE_ACCOUNT]

In diesem Mitgliedsnamen gilt:

  • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
  • KUBERNETES_NAMESPACE ist der Namespace des Kubernetes-Dienstkontos.
  • KUBERNETES_SERVICE_ACCOUNT ist der Name des Kubernetes-Dienstkontos, von dem die Anfrage stammt.

Das Konfigurieren von Workload Identity umfasst die Verwendung einer IAM-Richtlinienbindung, um den Namen des Mitglieds des Kubernetes-Dienstkontos an ein IAM-Dienstkonto zu binden, das die für Ihre Arbeitslasten erforderlichen Berechtigungen hat. Alle Google Cloud-API-Aufrufe von Arbeitslasten, die dieses Kubernetes-Dienstkonto verwenden, werden als gebundenes IAM-Dienstkonto authentifiziert.

Identitätsgleichheit

Der Mitgliedsname, über den IAM ein Kubernetes-Dienstkonto mit Workload Identity prüft, verwendet die folgenden Variablen:

  • Der Name des Kubernetes-Dienstkontos.
  • Der Namespace des Kubernetes-Dienstkontos.
  • Die Google Cloud-Projekt-ID.

Wenn Ihr Projekt mehrere Cluster mit demselben Namen und Namespace für ein Kubernetes-Dienstkonto hat, werden alle Konten in denselben Mitgliedsnamen aufgelöst. Mit dieser allgemeinen Identität können Sie dem Workload Identity-Pool anstelle von einzelnen Clustern Zugriff auf Google Cloud-Ressourcen gewähren.

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. Anwendungen im Namespace backend von Cluster A und Cluster B können sich beim Zugriff auf Google Cloud-Ressourcen als das IAM-Dienstkonto back authentifizieren. IAM unterscheidet nicht zwischen den Clustern, die die Aufrufe ausführen.

Diagramm zur Identitätsgleichheit in einem Workload Identity-Arbeitspool
Identitätgleichheit beim Zugriff auf Google Cloud APIs mit Workload Identity

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 IAM-Dienstkonto back 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 einen gemeinsamen Mitgliedsnamen zu vermeiden.

GKE-Metadatenserver

Die Metadaten jedes Knotens in GKE mit aktivierter Workload Identity 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.

Alternativen zu Workload Identity

Sie können eine der folgenden Alternativen zu Workload Identity verwenden, um über GKE auf Google Cloud APIs zuzugreifen.

  • Dienstkontoschlüssel exportieren und als Kubernetes-Secrets speichern. Google-Dienstkontoschlüssel laufen nicht ab und erfordern eine manuelle Rotation. Der Export von Dienstkontoschlüsseln kann den Umfang einer Sicherheitsverletzung vergrößern, wenn diese nicht erkannt wird. Wenn ein exportierter Schlüssel gestohlen wird, kann ein Angreifer ihn für die Authentifizierung als dieses Dienstkonto verwenden, bis Sie es bemerken und den Schlüssel manuell widerrufen.

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

Nächste Schritte