Dienstkonten in GKE

In diesem Dokument werden Dienstkonten in Google Kubernetes Engine (GKE) beschrieben und es wird erläutert, wie sie 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.

Dieses Dokument richtet sich an Sicherheitsexperten 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-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

CLUSTER_PROJECT_NUMBER ist die numerische Projektnummer des Projekts, das Ihren GKE-Cluster enthält.

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-CLUSTER_PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

CLUSTER_PROJECT_NUMBER ist die numerische Projektnummer des Projekts, das Ihren GKE-Cluster enthält.

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.

Node-Dienstkonten

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.

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

E-Mail-Adressen von Knotendienstkonten

Die E-Mail-Adresse Ihres Knotendienstkontos hängt vom Typ des Dienstkontos ab:

  • Standardmäßiges Compute Engine-Dienstkonto:

    CLUSTER_PROJECT_NUMBER-compute@developer.gserviceaccount.com

    Ersetzen Sie CLUSTER_PROJECT_NUMBER durch die Projektnummer des Projekts, das Ihren Cluster enthält, z. B. 1234567890.

  • Benutzerdefiniertes Dienstkonto:

    SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.com

    Ersetzen Sie Folgendes:

    • SERVICE_ACCOUNT_NAME: der Name des Dienstkontos.
    • SERVICE_ACCOUNT_PROJECT_ID: die Projekt-ID des Google Cloud -Projekts, das das Dienstkonto enthält.

Node-Dienstkonten und Projekt-Dienst-Agents

Wenn Sie einen Cluster oder Knotenpool erstellen, verwenden Dienst-Agents im Clusterprojekt das Dienstkonto, das an die Knoten angehängt ist, um Aufgaben wie das Pullen von Images auszuführen. Standardmäßig haben Dienst-Agents im Clusterprojekt den folgenden Zugriff auf Knotendienstkonten in diesem Projekt:

  • Der Compute Engine-Dienst-Agent in einem Projekt kann Zugriffstokens für Knotendienstkonten im selben Projekt erstellen.
  • Der GKE-Dienst-Agent in einem Projekt kann die Identität von Knotendienstkonten im selben Projekt übernehmen.

Einige Organisationen verwenden ein dediziertes Projekt, um alle Dienstkonten zu verwalten. Wenn sich das Dienstkonto Ihres Knotens nicht in Ihrem Clusterprojekt befindet, können die Dienst-Agents im Clusterprojekt keine Tokens erstellen oder dieses Dienstkonto übernehmen. Sie müssen den Dienst-Agents in Ihrem Clusterprojekt die folgenden Rollen für das Dienstkonto zuweisen:

  • Ersteller von Dienstkonto-Tokens (roles/iam.serviceAccountTokenCreator) für das Dienstkonto des Compute Engine-Dienst-Agents in Ihrem Clusterprojekt.
  • Dienstkontonutzer (roles/iam.serviceAccountUser) für das Dienstkonto des GKE-Dienst-Agents in Ihrem Clusterprojekt.

Weitere Informationen finden Sie unter Nutzung von Dienstkonten projektübergreifend konfigurieren.

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