Dienstkonten

Auf dieser Seite werden Dienstkonten, Arten von Dienstkonten und die IAM-Rollen beschrieben, die für Dienstkonten verfügbar sind.

Hinweis

• Sie sollten die grundlegenden Konzepte von IAM verstehen.

Was sind Dienstkonten?

Ein Dienstkonto ist ein spezieller Kontotyp, der nicht von einer Person, sondern von einer Anwendung oder einer VM-Instanz verwendet wird. Anwendungen verwenden Dienstkonten für autorisierte API-Aufrufe, die als Dienstkonto selbst oder als Google Workspace- oder Cloud Identity-Nutzer mithilfe domainweiter Delegation autorisiert werden.

Eine Compute Engine-VM kann beispielsweise als Dienstkonto ausgeführt werden, dem Berechtigungen für den Zugriff auf benötigte Ressourcen zugewiesen sind. Damit ist das Dienstkonto die Identität des Dienstes und die Berechtigungen des Dienstkontos bestimmen, auf welche Ressourcen der Dienst zugreifen kann.

Ein Dienstkonto wird durch seine E-Mail-Adresse definiert, die für das Konto spezifisch ist.

Unterschiede zwischen einem Dienstkonto und einem Nutzerkonto

Dienstkonten unterscheiden sich von Nutzerkonten in mehrfacher Hinsicht:

• Dienstkonten haben keine Passwörter und können sich nicht über Browser oder Cookies anmelden.
• Dienstkonten sind privaten und öffentlichen RSA-Schlüsselpaaren zugeordnet, die zur Authentifizierung bei Google verwendet werden.
• Sie können zulassen, dass andere Nutzer oder Dienstkonten die Identität eines Dienstkontos übernehmen.
• Dienstkonten gehören im Gegensatz zu Nutzerkonten nicht zu Ihrer Google Workspace-Domain. Wenn Sie beispielsweise Inhalte mit den Mitgliedern Ihrer Google Workspace-Domain teilen, werden diese nicht für Dienstkonten freigegeben. Ebenso können Google Workspace- oder Cloud Identity-Administratoren nicht Inhaber der von einem Dienstkonto erstellten Inhalte sein und diese nicht verwalten. Dies gilt nicht für die Verwendung der domainweiten Delegierung, da API-Aufrufe als imitierter Nutzer autorisiert werden, nicht als das Dienstkonto selbst.

Dienstkontoschlüssel

Jedem Dienstkonto sind zwei Sätze öffentlicher/privater RSA-Schlüsselpaare zugeordnet, die zur Authentifizierung bei Google verwendet werden: von Google verwaltete Schlüssel und vom Nutzer verwaltete Schlüssel.

Von Google verwaltete Schlüssel

Bei von Google verwalteten Schlüsselpaaren speichert Google sowohl den öffentlichen als auch den privaten Teil des Schlüssels und rotiert die Paare regelmäßig. Jeder Schlüssel kann maximal zwei Wochen lang zum Signieren verwendet werden. Der private Schlüssel wird immer treuhänderisch aufbewahrt und ist niemals direkt zugänglich. IAM stellt APIs bereit, um diese Schlüssel für die Anmeldung im Namen des Dienstkontos zu verwenden. Weitere Informationen finden Sie unter Kurzlebige Anmeldedaten für Dienstkonten erstellen.

Nutzerverwaltete Schlüssel

Nutzerverwaltete Schlüsselpaare implizieren, dass Sie sowohl den öffentlichen als auch den privaten Teil eines Schlüsselpaars haben. Sie können ein oder mehrere nutzerverwaltete Schlüsselpaare erstellen (sogenannte "externe" Schlüssel), die auch außerhalb von Google Cloud verwendet werden können. Google speichert nur den öffentlichen Teil eines nutzerverwalteten Schlüssels.

Außerdem können Sie einen öffentlichen Schlüssel im entsprechenden Format erstellen und in Google hochladen. Dort wird er dauerhaft mit dem angegebenen Dienstkonto verknüpft. Wenn Sie Signiervorgänge für dieses Dienstkonto ausführen müssen, z. B. beim Erstellen von Dienstkontoschlüsseln, wird dafür der hochgeladene öffentliche Schlüssel verwendet.

Der private Teil eines nutzerverwalteten Schlüsselpaars wird im Allgemeinen mit Standardanmeldedaten für Anwendungen verwendet. Der private Schlüssel wird dann zur Authentifizierung von Server-zu-Server-Anwendungen verwendet.

Bei nutzerverwalteten Schlüsseln sind Sie für die Sicherheit des privaten Schlüssels und andere Verwaltungsvorgänge wie die Schlüsselrotation verantwortlich. Nutzerverwaltete Schlüssel können über die IAM API, mit dem gcloud-Befehlszeilentool oder in der Google Cloud Console auf der Seite "Dienstkonten" verwaltet werden. Sie können bis zu 10 Dienstkontoschlüssel pro Dienstkonto erstellen, um eine Schlüsselrotation zu ermöglichen.

Sie können den Cloud Key Management Service (Cloud KMS) verwenden, um Schlüssel sicher zu verwalten.

Von Nutzern verwaltete Schlüssel eingeschränkt nutzen

Von Nutzern verwaltete Schlüssel sind äußerst leistungsstarke Anmeldedaten und können ein Sicherheitsrisiko darstellen, wenn sie nicht ordnungsgemäß verwaltet werden.

Sie können die Nutzung einschränken. Dazu wenden Sie die Beschränkung für Organisationsrichtlinien constraints/iam.disableServiceAccountKeyCreation auf Projekte, Ordner oder sogar auf Ihre gesamte Organisation an. Nach der Anwendung der Beschränkung können Sie nutzerverwaltete Schlüssel in kontrollierten Umgebungen aktivieren und so das potenzielle Risiko minimieren, das nicht verwaltete Schlüssel verursachen.

Arten von Dienstkonten

Nutzerverwaltete Dienstkonten

Sie können in Ihrem Projekt nutzerverwaltete Dienstkonten mit der IAM API, mit der Cloud Console oder mit dem gcloud-Befehlszeilentool erstellen. Dabei sind Sie für die Verwaltung und Sicherung dieser Konten verantwortlich.

Standardmäßig können Sie bis zu 100 Dienstkonten mit Nutzerverwaltung in einem Projekt erstellen. Wenn dieses Kontingent für Ihre Anforderungen nicht ausreicht, haben Sie die Möglichkeit, über die Cloud Console eine Kontingenterhöhung anzufordern. Die auf dieser Seite beschriebenen Standarddienstkonten werden nicht auf dieses Kontingent angerechnet.

Wenn Sie in Ihrem Projekt ein nutzerverwaltetes Dienstkonto erstellen, müssen Sie einen Namen für das Dienstkonto festlegen. Dieser Name erscheint in der E-Mail-Adresse, die das Dienstkonto identifiziert. Diese hat folgendes Format:

[e-mail]

Standarddienstkonten

Bei bestimmten Google Cloud-Diensten werden nutzerverwaltete Dienstkonten erstellt, mit denen der Dienst Jobs bereitstellen kann, die auf andere Google Cloud-Ressourcen zugreifen. Diese Konten werden als Standarddienstkonten bezeichnet.

Die Standarddienstkonten erleichtern den Einstieg in Google Cloud-Dienste. Für Produktionsarbeitslasten empfehlen wir dringend, eigene nutzerverwaltete Dienstkonten zu erstellen und jedem Dienstkonto die entsprechenden Rollen zuzuweisen.

Wenn ein Standarddienstkonto erstellt wird, erhält es automatisch die Rolle "Bearbeiter" (roles/editor) für Ihr Projekt. Diese Rolle umfasst eine Vielzahl von Berechtigungen. Zur Beachtung des Prinzips der geringsten Berechtigung empfehlen wir dringend, die automatische Rollenzuweisung zu deaktivieren. Dazu fügen Sie Ihrer Organisationsrichtlinie eine Einschränkung hinzu oder widerrufen die Bearbeiterrolle manuell. Wenn Sie die Rollenzuweisung deaktivieren oder widerrufen, müssen Sie festlegen, welche Rollen den Standarddienstkonten zugeteilt werden sollen.

In der folgenden Tabelle sind die Dienste aufgeführt, die Standarddienstkonten erstellen:

Dienst	Name des Dienstkontos	E-Mail-Adresse
App Engine und alle Google Cloud-Dienste, die App Engine nutzen	App Engine-Standarddienstkonto	[e-mail]
Compute Engine und alle Google Cloud-Dienste, die Compute Engine nutzen	Compute Engine-Standarddienstkonto	[e-mail]

Wichtig: Sowohl das Erstellungsdatum als auch das E-Mail-Adressformat von Standarddienstkonten können geändert werden.

Von Google verwaltete Dienstkonten

Einige Google Cloud-Dienste benötigen Zugriff auf Ihre Ressourcen, damit sie Aufgaben für Sie ausführen können. Wenn Sie beispielsweise einen Container mit Cloud Run ausführen, benötigt der Dienst Zugriff auf alle Pub/Sub-Themen, die den Container auslösen können.

Damit dies möglich ist, erstellt und verwaltet Google Dienstkonten für viele Google Cloud-Dienste. Diese Dienstkonten werden als von Google verwaltete Dienstkonten bezeichnet. Möglicherweise sehen Sie von Google verwaltete Dienstkonten in der IAM-Richtlinie und den Audit-Logs Ihres Projekts.

Wichtig: Das Erstellungsdatum und das E-Mail-Adressformat für diese Dienstkonten können sich ändern.

Beispiel:

• Google APIs-Dienst-Agent: Ihr Projekt enthält wahrscheinlich ein Dienstkonto namens Google APIs-Dienst-Agent mit einer E-Mail-Adresse im folgenden Format [e-mail].

  Dieses Dienstkonto führt in Ihrem Namen interne Google-Prozesse aus. Es erhält automatisch die Rolle "Bearbeiter" (roles/editor) für das Projekt.

  Warnung: Ändern oder widerrufen Sie die Rollen nicht, die dem Google APIs-Dienst-Agent zugewiesen sind. Wenn Sie diese Rollen ändern oder widerrufen, funktionieren einige Google Cloud-Dienste nicht mehr.

• Rollenmanager für von Google verwaltete Dienstkonten: Ihre Audit-Logs für IAM beziehen sich möglicherweise auf das Dienstkonto [e-mail].

  Dieses Dienstkonto verwaltet die Rollen, die anderen von Google verwalteten Dienstkonten zugewiesen werden. Es ist nur in Audit-Logs sichtbar.

  Wenn Sie beispielsweise eine neue API verwenden, kann es sein, dass Google automatisch ein neues von Google verwaltetes Dienstkonto erstellt und dem Dienstkonto in Ihrem Projekt Rollen zuweist. Durch das Zuweisen dieser Rollen wird ein Audit-Logeintrag generiert, aus dem hervorgeht, dass [e-mail] die IAM-Richtlinie für das Projekt festgelegt hat.

• Andere von Google verwaltete Dienstkonten: Ihr Projekt kann weitere von Google verwaltete Dienstkonten enthalten, die im Namen einzelner Dienste agieren. Diese Dienstkonten werden manchmal als Dienst-Agents bezeichnet. Diesen Dienst-Agents können automatisch Rollen zugewiesen werden. Die Namen dieser Rollen enden normalerweise auf serviceAgent.

  Warnung: Sie dürfen die Rollen, die Dienst-Agents zugewiesen sind, weder ändern noch entziehen. Wenn Sie diese Rollen ändern oder entziehen, funktionieren einige Google Cloud-Dienste nicht mehr.

  Eine vollständige Liste der Dienst-Agents und der Rollen, die jedem einzelnen automatisch zugewiesen werden, finden Sie unter Dienst-Agents.

Dienstkontoberechtigungen

Ein Dienstkonto ist nicht nur eine Identität, sondern auch eine Ressource, der IAM-Richtlinien zugewiesen sind. Durch diese Richtlinien wird bestimmt, wer das Dienstkonto nutzen kann.

Alice kann beispielsweise die Bearbeiterrolle und Bob die Betrachterrolle für ein Dienstkonto haben. Dies entspricht dem Zuweisen von Rollen für andere Google Cloud-Ressourcen.

Den standardmäßigen Compute Engine- und App Engine-Dienstkonten werden Bearbeiterrollen für das Projekt zugewiesen, wenn sie erstellt werden, wodurch der Code, der in Ihrer App- oder VM-Instanz ausgeführt wird, die erforderlichen Berechtigungen hat. In diesem Fall sind die Dienstkonten Identitäten, denen die Bearbeiterrolle für eine Ressource (Projekt) zugewiesen ist.

Wenn Sie Ihrer Anwendung den Zugriff auf einen Cloud Storage-Bucket gewähren möchten, gewähren Sie dem Dienstkonto, das Ihre Anwendung verwendet, die Berechtigungen zum Lesen des Cloud Storage-Buckets. In diesem Fall ist das Dienstkonto die Identität, der Sie Berechtigungen für eine andere Ressource (den Cloud Storage-Bucket) gewähren.

Rolle "Dienstkontonutzer"

Sie können die Rolle des Dienstkontonutzers (roles/iam.serviceAccountUser) auf Projektebene für alle Dienstkonten im Projekt oder auf Dienstkontoebene zuweisen.

• Wenn einem Nutzer die Rolle des Dienstkontonutzers für ein Projekt zugewiesen wird, erhält er Zugriff auf alle Dienstkonten im Projekt, einschließlich Dienstkonten, die möglicherweise in Zukunft erstellt werden.

• Wenn einem Nutzer die Rolle des Dienstkontonutzers für ein bestimmtes Dienstkonto zugewiesen wird, erhält er nur Zugriff auf dieses Dienstkonto.

Nutzer, denen die Rolle des Dienstkontonutzers für ein Dienstkonto zugewiesen wurde, können damit indirekt auf alle Ressourcen zugreifen, auf die das Dienstkonto Zugriff hat. Beispiel: Einem Dienstkonto wurde die Rolle des Compute-Administrators (roles/compute.admin) zugewiesen. Ein Nutzer mit der Rolle "Dienstkontonutzer" (roles/iam.serviceAccountUser) für dieses Dienstkonto kann im Namen dieses Dienstkontos eine Compute Engine-Instanz starten. In diesem Ablauf übernimmt der Nutzer die Identität des Dienstkontos, um über die ihm zugewiesenen Rollen und Berechtigungen Aufgaben auszuführen.

Weitere Informationen zum Zuweisen von Nutzerrollen für Dienstkonten finden Sie unter Identitätswechsel für Dienstkonten verwalten.

Hinweis: In Szenarien, in denen einem Dienstkonto Berechtigungen zum Ausführen von Vorgängen mit umfangreichen Rechten gewährt wurden, sollten Sie vorsichtig sein, wenn Sie einem Nutzer die Rolle "Dienstkontonutzer" für dieses Dienstkonto zuweisen.

Dienstkonten stehen für Ihre Sicherheit auf Dienstebene. Die Sicherheit des Dienstes ist abhängig von den Personen, die IAM-Rollen für die Verwaltung und Verwendung der Dienstkonten haben, und den Personen, die private externe Schlüssel für diese Dienstkonten haben. Best Practices für die Sicherheit sind z. B. folgende Maßnahmen:

• Prüfen Sie mithilfe der IAM API die Dienstkonten, die Schlüssel und die Richtlinien für diese Dienstkonten.
• Wenn Ihre Dienstkonten keine externen Schlüssel erfordern, löschen Sie diese.
• Wenn Nutzer keine Berechtigung zum Verwalten oder Verwenden von Dienstkonten benötigen, entfernen Sie sie aus der entsprechenden IAM-Richtlinie.
• Sorgen Sie dafür, dass Dienstkonten so wenig Berechtigungen wie möglich haben. Verwenden Sie Standarddienstkonten mit Vorsicht, da ihnen automatisch die Rolle "Bearbeiter" (roles/editor) für das Projekt zugewiesen wird.

Weitere Informationen zu Best Practices finden Sie unter Details zu Dienstkonten.

Rolle "Ersteller von Dienstkonto-Token"

Diese Rolle ermöglicht den Identitätswechsel von Dienstkonten, um OAuth2-Zugriffstoken zu erstellen oder Blobs oder JWTs zu signieren.

Rolle "Dienstkontonutzer"

Diese Rolle wurde eingestellt. Wenn Sie Vorgänge mit einem Dienstkonto ausführen müssen, verwenden Sie die Rolle Dienstkontobenutzer. Sie sollten auch die Rolle Ersteller von Dienstkonto-Tokens zuweisen, um effektiv dieselben Berechtigungen wie für "Dienstkontonutzer" (Service Account Actor) zu gewähren.

Zugriffsbereiche

Zugriffsbereiche sind die Legacy-Methode zum Festlegen von Berechtigungen für Ihre VM. Als es noch keine IAM-Rollen gab, konnten Berechtigungen für Dienstkonten nur über Zugriffsbereiche erteilt werden. Obwohl Zugriffsbereiche jetzt nicht mehr die primäre Methode zum Zuweisen von Berechtigungen sind, müssen Sie sie auch weiterhin festlegen, wenn Sie eine Instanz konfigurieren, die als Dienstkonto ausgeführt werden soll. Informationen zu Zugriffsbereichen finden Sie in der Google Compute Engine-Dokumentation.

Kurzlebige Anmeldedaten für das Dienstkonto

Sie können kurzlebige Anmeldedaten erstellen, mit denen Sie die Identität eines Google Cloud-Dienstkontos annehmen können. Diese Anmeldedaten können zur Authentifizierung von Aufrufen an Google Cloud APIs oder Drittanbieter-APIs verwendet werden.

Der häufigste Anwendungsfall für diese Anmeldedaten besteht darin, den Zugriff auf Google Cloud-Ressourcen für verschiedene Projekte, Organisationen oder Konten vorübergehend zu delegieren. Beispielsweise kann ein vorübergehender Notfallzugriff gewährt werden, statt permanente Anmeldedaten für ein Dienstkonto mit umfangreichen Berechtigungen für einen externen Aufrufer bereitzustellen. Alternativ kann die Identität eines zugewiesenen Dienstkontos mit weniger Berechtigungen von einem externen Aufrufer übernommen werden, ohne dass die Anmeldedaten eines Dienstkontos mit umfangreicheren Berechtigungen erforderlich ist.

Weitere Informationen finden Sie unter Kurzlebige Anmeldedaten für das Dienstkonto erstellen.

Workload Identity-Föderation

Beta

Dieses Feature ist eine Vorabveröffentlichung, für die möglicherweise nur eingeschränkter Support verfügbar ist. Änderungen sind jederzeit möglich. Weitere Informationen zu unseren Markteinführungsphasen finden Sie hier.

Sie können Identitäten von Arbeitslasten, die außerhalb von Google Cloud ausgeführt werden, z. B. auf Amazon Web Services (AWS) oder Microsoft Azure, die Möglichkeit geben, die Identität eines Dienstkontos zu übernehmen. So lässt sich mithilfe kurzlebiger Anmeldedaten direkt auf Ressourcen zugreifen, anstatt einen Dienstkontoschlüssel zu verwenden.

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

Standardanmeldedaten für Anwendungen

Standardanmeldedaten für Anwendungen erleichtern die Nutzung von Dienstkonten bei der Verwendung innerhalb und außerhalb von Google Cloud sowie in mehreren Google Cloud-Projekten. Der häufigste Anwendungsfall ist das Testen von Code auf einem lokalen Computer, um diesen dann in ein Entwicklungsprojekt in Google Cloud und später in ein Produktionsprojekt in Google Cloud zu verschieben. Mit Standardanmeldedaten für Anwendungen wird sichergestellt, dass das Dienstkonto reibungslos funktioniert. Beim Testen auf Ihrem lokalen Computer wird ein lokal gespeicherter Dienstkontoschlüssel verwendet. Bei der Ausführung in Compute Engine wird jedoch das standardmäßige Compute Engine-Dienstkonto des Projekts verwendet. Weitere Informationen finden Sie unter Standardanmeldedaten für Anwendungen.

Weitere Informationen

Best Practices für die Verwendung von Dienstkonten finden Sie unter Informationen zu Dienstkonten.

Die folgenden Anleitungen enthalten weitere Informationen:

• Dienstkonten erstellen und verwalten
• Dienstkontoschlüssel erstellen und verwalten
• Allen Mitgliedstypen IAM-Rollen zuweisen, einschließlich Dienstkonten.