Identitäten für Arbeitslasten

Google Cloud stellt Dienstkonten bereit, die 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.

Es gibt verschiedene Möglichkeiten, Dienstkonten als Identitäten für Arbeitslasten zu konfigurieren. Welche Methoden Sie verwenden können, 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
  • Verwaltete Workload Identities (nur für Arbeitslasten, die in Compute Engine ausgeführt werden)
  • Workload Identity (nur für Arbeitslasten, die in Google Kubernetes 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.

Verwaltete Arbeitslastidentitäten

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

Weitere Informationen zu verwalteten Workload Identity finden Sie unter Übersicht über verwaltete Arbeitslastidentitäten.

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

GKE Workload Identity

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

Weitere Informationen zu Identitätsföderation von Arbeitslasten für GKE.

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. Dienstkontoschlüssel stellen ein Sicherheitsrisiko dar, wenn sie nicht ordnungsgemäß verwaltet werden. Sie sollten nach Möglichkeit eine sicherere Alternative zu Dienstkontoschlüsseln auswählen. Wenn Sie sich mit einem Dienstkontoschlüssel authentifizieren müssen, sind Sie für die Sicherheit des privaten Schlüssels und für andere Vorgänge verantwortlich, die unter Best Practices für die Verwaltung von Dienstkontoschlüsseln beschrieben werden. Wenn Sie keinen Dienstkontoschlüssel erstellen können, wird das Erstellen von Dienstkontoschlüsseln für Ihre Organisation möglicherweise deaktiviert. Weitere Informationen finden Sie unter Standardmäßig sichere Organisationsressourcen verwalten.

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:

  • Identitätsföderation von Arbeitslasten
  • Dienstkontoschlüssel

Identitätsföderation von Arbeitslasten

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 zu Identitätsföderation von Arbeitslasten.

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. Dienstkontoschlüssel stellen ein Sicherheitsrisiko dar, wenn sie nicht ordnungsgemäß verwaltet werden. Sie sollten nach Möglichkeit eine sicherere Alternative zu Dienstkontoschlüsseln auswählen. Wenn Sie sich mit einem Dienstkontoschlüssel authentifizieren müssen, sind Sie für die Sicherheit des privaten Schlüssels und für andere Vorgänge verantwortlich, die unter Best Practices für die Verwaltung von Dienstkontoschlüsseln beschrieben werden. Wenn Sie keinen Dienstkontoschlüssel erstellen können, wird das Erstellen von Dienstkontoschlüsseln für Ihre Organisation möglicherweise deaktiviert. Weitere Informationen finden Sie unter Standardmäßig sichere Organisationsressourcen verwalten.

Lokale Entwicklung

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

Nächste Schritte