Dienstkonten in GKE

Auf dieser Seite werden Dienstkonten in Google Kubernetes Engine (GKE) beschrieben, die Identitäten für Anwendungen bereitstellen. Sie erfahren mehr über die verschiedenen Arten von Dienstkonten und wann Sie die einzelnen Typen verwenden sollten, um den Zugriff auf Ressourcen in GKE zu authentifizieren, ohne auf persönliche Anmeldedaten angewiesen zu sein.

Diese Seite richtet sich an Sicherheitsspezialisten und Bediener, die Dienstkonten für die Interaktion mit GKE-Anwendungen erstellen und verwalten. 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.

Kubernetes-Dienstkonten und IAM-Dienstkonten

In der folgenden Tabelle werden die Hauptunterschiede zwischen Kubernetes-Dienstkonten und IAM-Dienstkonten beschrieben:

Arten von Dienstkonten in GKE
Kubernetes-Dienstkonto
  • Objekt ServiceAccount im Kubernetes API-Server
  • Auf einen Kubernetes-Namespace in einem Cluster beschränkt
  • Stellt eine Identität für Pods bereit, die im Cluster verwendet werden sollen
IAM-Dienstkonto
  • Mit der IAM API verwalten
  • Auf ein Google Cloud -Projekt beschränkt
  • Stellt eine Identität für Anwendungen im Projekt bereit

Kubernetes-Dienstkonten

Kubernetes-Dienstkonten werden auf Clusterebene verwaltet und sind auf dem Kubernetes API-Server als ServiceAccount-Objekte vorhanden. In der Kubernetes- und GKE-Dokumentation wird häufig der Begriff ServiceAccount verwendet, um diese Kubernetes-Ressourcen von Dienstkonten in anderen Umgebungen wie IAM zu unterscheiden.

Sie erstellen ein Kubernetes-ServiceAccount in einem Namespace und weisen dieses ServiceAccount dann mithilfe des Felds serviceAccountName im Pod-Manifest einem Pod zu. Der Kubelet-Prozess auf dem Knoten ruft ein kurzlebiges Inhabertoken für das zugewiesene ServiceAccount ab und stellt das Token als projiziertes Volume im Pod bereit. Standardmäßig hat dieses projizierte Volume einen Namen, der mit dem Präfix kube-api-access- beginnt. Alle Volumes, die mit diesem Präfix beginnen, werden von GKE verwaltet. Das bedeutet, dass Sie die Größe dieser Volumes nicht ändern können. Wenn Sie die Festplattennutzung genauer überwachen möchten, schließen Sie Volumes, die mit dem Präfix kube-api-access- beginnen, aus Ihrer Monitoringkonfiguration aus.

Das kurzlebige Inhabertoken ist ein JSON Web Token (JWT), das vom API-Server signiert wird, bei dem es sich um einen OIDC-Anbieter (OpenID Connect) handelt. Rufen Sie zum Validieren des Inhabertokens den öffentlichen Validierungsschlüssel für den Cluster ab. Rufen Sie dazu die Methode projects.locations.clusters.getJwks in der GKE API auf.

Gefährdete Anmeldedaten des Kubernetes-Dienstkontos

Wenn die Anmeldedaten eines Kubernetes-Dienstkontos manipuliert wurden, verwenden Sie eine der folgenden Optionen, um die Anmeldedaten zu widerrufen:

  • Pods neu erstellen: Das Inhabertoken ist an jede eindeutige Pod-UID gebunden. Daher werden beim Neuerstellen der Pods die vorherigen Anmeldedaten ungültig.
  • Erstellen Sie das Kubernetes-Dienstkonto neu: Das Inhabertoken ist an die UID des ServiceAccount-Objekts in der Kubernetes API gebunden. Löschen Sie das ServiceAccount und erstellen Sie ein neues ServiceAccount mit dem gleichen Namen. Frühere Tokens werden ungültig, da die UID des neuen ServiceAccount anders ist.
  • Rotation von Anmeldedaten durchführen: Bei diesem Vorgang werden alle Anmeldedaten von Kubernetes-Dienstkonten in Ihrem Cluster widerrufen. Durch die Rotation werden auch das CA-Zertifikat und die IP-Adresse Ihres Clusters geändert. Weitere Informationen finden Sie unter Rotation von Anmeldedaten.

IAM-Dienstkonten

IAM-Dienstkonten werden auf Projektebene mithilfe der IAM API verwaltet. Sie können diese Dienstkonten verwenden, um Aktionen wie das programmatische Aufrufen von Google Cloud-APIs und das Verwalten von Berechtigungen für Anwendungen auszuführen, die in Google Cloud-Produkten ausgeführt werden.

Weitere Informationen finden Sie in der Übersicht zu IAM-Dienstkonten.

GKE-Dienst-Agents

Ein IAM-Dienst-Agent ist ein IAM-Dienstkonto, das von Google Cloud verwaltet wird. GKE verwendet die folgenden beiden Dienst-Agents:

Kubernetes Engine-Dienst-Agent

GKE verwendet den Kubernetes Engine-Dienst-Agent, um den Lebenszyklus von Clusterressourcen wie Knoten, Laufwerke und Load-Balancer in Ihrem Namen zu verwalten. Dieser Dienst-Agent hat die Domain container-engine-robot.iam.gserviceaccount.com und erhält die Rolle Kubernetes-Engine-Service-Agent (roles/container.serviceAgent) in Ihrem Projekt, wenn Sie die GKE-API aktivieren.

Die Kennung dieses Dienst-Agents lautet:

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

PROJECT_NUMBER ist Ihre numerische Projektnummer.

Kubernetes Engine Default Node Service Agent

GKE verwendet den Kubernetes Engine-Standarddienst-Agent für Knoten, um das Logging und Monitoring von Kubernetes-Knoten für Cluster mit Kubernetes-Version 1.33 und höher zu unterstützen. Dieser Dienst-Agent hat die Domain gcp-sa-gkenode.iam.gserviceaccount.com und erhält die Rolle Kubernetes Engine Default Node Service Agent (roles/container.defaultNodeServiceAgent) in Ihrem Projekt, wenn Sie die GKE API aktivieren.

Die Kennung dieses Dienst-Agents lautet:

service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

PROJECT_NUMBER ist Ihre numerische Projektnummer.

Wenn Sie die Berechtigungen des Dienst-Agents in Ihrem Projekt entfernen, können Sie sie wiederherstellen. Folgen Sie dazu der Anleitung unter Fehler 400/403: Dem Konto fehlen Bearbeitungsberechtigungen.

Standardmäßiges GKE-Knotendienstkonto

GKE verwendet IAM-Dienstkonten, die an Ihre Knoten angehängt sind, um Systemaufgaben wie Logging und Monitoring auszuführen. Diese Knoten-Dienstkonten müssen in Ihrem Projekt mindestens die Rolle Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) haben. Standardmäßig verwendet GKE das Compute Engine-Standarddienstkonto, das automatisch in Ihrem Projekt erstellt wird, als Knotendienstkonto.

Wenn Ihre Organisation die Einschränkung der Organisationsrichtlinie iam.automaticIamGrantsForDefaultServiceAccounts erzwingt, erhält das Compute Engine-Standarddienstkonto in Ihrem Projekt möglicherweise nicht automatisch die erforderlichen Berechtigungen für GKE.

Wenn Sie das Compute Engine-Standarddienstkonto für andere Funktionen in Ihrem Projekt oder Ihrer Organisation verwenden, hat das Dienstkonto möglicherweise mehr Berechtigungen als für GKE erforderlich. Dies kann zu Sicherheitsrisiken führen.

So weisen Sie dem Compute Engine-Standarddienstkonto die Rolle roles/container.defaultNodeServiceAccount zu:

Console

  1. Rufen Sie die Seite Willkommen auf:

    Zur Begrüßungsseite

  2. Klicken Sie im Feld Projektnummer auf  In die Zwischenablage kopieren.
  3. Rufen Sie die IAM-Seite auf.

    IAM aufrufen

  4. Klicken Sie auf Zugriffsrechte erteilen.
  5. Geben Sie im Feld Neue Hauptkonten den folgenden Wert an: 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     Ersetzen Sie PROJECT_NUMBER durch die kopierte Projektnummer.
  6. Wählen Sie im Menü Rolle auswählen die Rolle Kubernetes Engine Default Node Service Account aus.
  7. Klicken Sie auf Speichern.

gcloud

  1. So finden Sie Ihre Google Cloud Projektnummer: 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

    Die Ausgabe sieht etwa so aus:

    12345678901
  2. Weisen Sie dem Compute Engine-Standarddienstkonto die Rolle roles/container.defaultNodeServiceAccount zu: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    Ersetzen Sie PROJECT_NUMBER durch die Projektnummer aus dem vorherigen Schritt.

Deaktivieren Sie das Compute Engine-Standarddienstkonto nur, wenn Sie zu von Nutzern verwalteten Dienstkonten migrieren.

Wann sollte ein bestimmtes Dienstkonto verwendet werden?

Welche Art von Dienstkonto Sie verwenden, hängt von der Art der Identität ab, die Sie für Ihre Anwendungen bereitstellen möchten:

  • Identität für die Pods zur Verwendung im Cluster bereitstellen: Verwenden Sie ein Kubernetes-ServiceAccount. Jeder Kubernetes-Namespace hat ein default-ServiceAccount. Wir empfehlen jedoch, für jede Arbeitslast in jedem Namespace neue ServiceAccounts mit minimalen Berechtigungen zu erstellen.
  • Identität für Pods zur Verwendung außerhalb des Clusters bereitstellen: Verwenden Sie Workload Identity-Föderation für GKE. Mit Workload Identity Federation für GKE können Sie Kubernetes-Ressourcen wie ServiceAccounts als Hauptkonten in IAM-Richtlinien angeben. Verwenden Sie beispielsweise die Identitätsföderation von Arbeitslasten für GKE, wenn Sie Google Cloud APIs wie Secret Manager oder Spanner über Ihre Pods aufrufen.
  • Standardidentität für Knoten bereitstellen: Verwenden Sie beim Erstellen von GKE-Clustern oder -Knoten ein benutzerdefiniertes IAM-Dienstkonto mit minimal Berechtigungen. Wenn Sie kein benutzerdefiniertes IAM-Dienstkonto verwenden, nutzt GKE das Compute Engine-Standarddienstkonto.

Nächste Schritte