Identitäten für Arbeitslasten

Google Cloud bietet die folgenden Identitätstypen für Arbeitslasten:

  • Mit der Workload Identity-Föderation und der Workload Identity-Föderation für GKE können Ihre Arbeitslasten über föderierte Identitäten, die über einen externen Identitätsanbieter (Identity Provider, IdP) authentifiziert werden, auf die meisten Google Cloud-Dienste zugreifen. Nachdem Google Cloud die Identität als Hauptkonto authentifiziert hat, kann das Hauptkonto mithilfe der von Ihnen gewährten IAM-Rollen auf Ressourcen zugreifen.

    Sie können die Workload Identity-Föderation mit Arbeitslasten in Google Cloud oder externen Arbeitslasten verwenden, die auf Plattformen wie AWS, Azure, GitHub und GitLab ausgeführt werden.

    Sie können die Workload Identity-Föderation für GKE mit Arbeitslasten verwenden, die in GKE-Clustern ausgeführt werden, um ihnen Zugriff auf Google Cloud-Ressourcen zu gewähren.

  • Google Cloud-Dienstkonten können als Identitäten für Arbeitslasten in Produktionsumgebungen fungieren. Anstatt direkt auf eine Arbeitslast Zugriff zu erteilen, gewähren Sie einen Zugriff auf ein Dienstkonto und lassen die Arbeitslast dann das Dienstkonto als Identität verwenden.

  • Mit verwalteten Arbeitslastidentitäten (Vorabversion) können Sie stark attestierte Identitäten an Ihre Compute Engine-Arbeitslasten binden. Sie können verwaltete Arbeitslastidentitäten verwenden, um Ihre Arbeitslasten über gegenseitiges TLS (mTLS) bei anderen Arbeitslasten zu authentifizieren. Sie können sie jedoch nicht für die Authentifizierung bei Google Cloud APIs verwenden.

Welche Identitätstypen Sie für Arbeitslasten verwenden und wie Sie sie konfigurieren, hängt davon ab, wo Ihre Arbeitslasten ausgeführt werden.

Arbeitslasten in Google Cloud

Wenn Sie Arbeitslasten in Google Cloud ausführen, können Sie mit den folgenden Methoden Identitäten für Ihre Arbeitslasten konfigurieren:

  • Angehängte Dienstkonten
  • Workload Identity-Föderation für GKE (nur für Arbeitslasten, die in Google Kubernetes Engine ausgeführt werden)
  • Verwaltete Arbeitslastidentitäten (nur für Arbeitslasten, die in Compute Engine ausgeführt werden)
  • Dienstkontoschlüssel

Angehängte Dienstkonten

Bei einigen Google Cloud-Ressourcen können Sie ein nutzerverwaltetes Dienstkonto angeben, das von der Ressource als Standardidentität verwendet wird. Dieser Vorgang wird als Anhängen des Dienstkontos an die Ressource oder Verknüpfen des Dienstkontos mit der Ressource bezeichnet. Wenn Code, der auf der Ressource ausgeführt wird, auf Google Cloud-Dienste und -Ressourcen zugreift, verwendet er das an die Ressource angehängte Dienstkonto als Identität. Beispiel: Sie hängen ein Dienstkonto an eine Compute Engine-Instanz an und die Anwendungen auf der Instanz verwenden eine Clientbibliothek, um Google Cloud APIs aufzurufen. Diese Anwendungen verwenden automatisch das angehängte Dienstkonto für die Authentifizierung und Autorisierung.

In den meisten Fällen müssen Sie beim Erstellen einer Ressource ein Dienstkonto an eine Ressource anhängen. Nachdem die Ressource erstellt wurde, können Sie nicht mehr ändern, welches Dienstkonto an der Ressource angehängt ist. Compute Engine-Instanzen sind eine Ausnahme von dieser Regel. Sie können je nach Bedarf ändern, welches Dienstkonto an eine Instanz angehängt ist.

Weitere Informationen zu Dienstkonto an eine Ressource anhängen.

Workload Identity Federation for GKE

Bei Arbeitslasten, die in GKE ausgeführt werden, können Sie mit der Workload Identity-Föderation für GKE für jede Anwendung in Ihrem Cluster separate, detaillierte Hauptkonten IAM-Rollen zuweisen. Mit der Identitätsföderation von Arbeitslasten für GKE können Kubernetes-Dienstkonten in Ihrem GKE-Cluster direkt über die Workforce Identity-Föderation oder indirekt über die Identitätsdiebstahl-Funktion von IAM-Dienstkonten auf Google Cloud-Ressourcen zugreifen.

Wenn Sie den direkten Ressourcenzugriff verwenden, können Sie der Identität des Kubernetes-Dienstkontos direkt auf den Ressourcen des Google Cloud-Dienstes IAM-Rollen zuweisen. Die meisten Google Cloud APIs unterstützen den direkten Ressourcenzugriff. Bei der Verwendung der Identitätsföderation können jedoch bestimmte API-Methoden eingeschränkt sein. Eine Liste dieser Einschränkungen finden Sie unter Unterstützte Produkte und Einschränkungen.

Alternativ können Arbeitslasten auch die Dienstkonto-Identitätsdiebstahl-Methode verwenden. Dabei ist das konfigurierte Kubernetes-Dienstkonto an ein IAM-Dienstkonto gebunden, das beim Zugriff auf Google Cloud APIs als Identität dient.

Weitere Informationen zur Identitätsföderation von Arbeitslasten für GKE finden Sie unter Identitätsföderation von Arbeitslasten für GKE.

Verwaltete Arbeitslastidentitäten

Mit verwalteten Arbeitslastidentitäten können Sie Ihre Compute Engine-Arbeitslasten an stark attestierte Identitäten binden. Sie können verwaltete Arbeitslastidentitäten verwenden, um Ihre Arbeitslasten mit mTLS bei anderen Arbeitslasten zu authentifizieren. Sie können jedoch nicht für die Authentifizierung bei Google Cloud APIs verwendet werden.

Weitere Informationen zu verwalteten Workload-Identitäten finden Sie unter Verwaltete Workload-Identitäten – Übersicht.

Weitere Informationen zur Verwendung verwalteter Arbeitslastidentitäten mit Compute Engine-Arbeitslasten finden Sie unter Arbeitslasten über mTLS bei anderen Arbeitslasten authentifizieren.

Externe Arbeitslasten

Wenn Sie Arbeitslasten außerhalb von Google Cloud ausführen, können Sie mit den folgenden Methoden Identitäten für Ihre Arbeitslasten konfigurieren:

  • Workload Identity-Föderation
  • Dienstkontoschlüssel

Workload Identity-Föderation

Mit der Identitätsföderation von Arbeitslasten können Sie Anmeldedaten von externen Identitätsanbietern wie AWS und Azure Active Directory verwenden, um kurzlebige Anmeldedaten zu generieren, mit denen Arbeitslasten vorübergehend die Identität von Dienstkonten übernehmen können. Arbeitslasten können dann über das Dienstkonto als Identität auf Google Cloud-Ressourcen zugreifen.

Die Identitätsföderation von Arbeitslasten ist die bevorzugte Methode zum Konfigurieren von Identitäten für externe Arbeitslasten.

Weitere Informationen zur Workload Identity-Föderation finden Sie unter Workload Identity-Föderation.

Dienstkontoschlüssel

Mit einem Dienstkontoschlüssel kann sich eine Arbeitslast als Dienstkonto authentifizieren und dann die Identität des Dienstkontos für die Autorisierung verwenden.

Lokale Entwicklung

Wenn Sie Entwicklungen in einer lokalen Umgebung durchführen, können Sie Arbeitslasten so konfigurieren, dass entweder Ihre Nutzeranmeldedaten oder ein Dienstkonto für die Authentifizierung und Autorisierung verwendet werden. Weitere Informationen finden Sie in der Authentifizierungsdokumentation im Artikel Lokale Entwicklungsumgebung.

Nächste Schritte