Dienstkonten

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

Hinweis

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 Google Workspace-Assets wie Dokumente oder Ereignisse für alle Mitglieder in Ihrer Google Workspace-Domain freigeben, werden diese nicht für Dienstkonten freigegeben. Ebenso werden von einem Dienstkonto erstellte Google Workspace-Assets nicht in Ihrer Google Workspace-Domain erstellt. Ihre Google Workspace- und Cloud Identity-Administratoren können diese Assets dann weder besitzen noch verwalten.

Erstellung von Dienstkonten verhindern

Um das Erstellen von Dienstkonten zu verhindern, erzwingen Sie die Einschränkung der Organisationsrichtlinien constraints/iam.disableServiceAccountCreation in einer Organisation, einem Projekt oder einem Ordner.

Beachten Sie folgende Einschränkungen, bevor Sie diese Einschränkung erzwingen:

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.

Erstellung von benutzerverwalteten Schlüsseln verhindern

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

Wenn Sie die Verwendung von nutzerverwalteten Schlüsseln einschränken möchten, können Sie die folgenden Einschränkungen für Organisationsrichtlinien für eine Organisation, ein Projekt oder einen Ordner erzwingen:

  • constraints/iam.disableServiceAccountKeyCreation: verhindert, dass Mitglieder nutzerverwaltete Dienstkontoschlüssel erstellen.
  • constraints/iam.disableServiceAccountKeyUpload: verhindert, dass Mitglieder einen öffentlichen Schlüssel für ein Dienstkonto hochladen.

Wenn Sie diese Einschränkungen erzwingen, weil Sie die Workload Identity Federation verwenden, können Sie mit den Einschränkungen für Organisationsrichtlinien für die Workload Identity Federation angeben, welche Identitätsanbieter zulässig sind.

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:

service-account-name@project-id.iam.gserviceaccount.com

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.

Wenn Ihre Anwendung in einer Google Cloud-Umgebung mit einem Standarddienstkonto ausgeführt wird, kann sie mit den Anmeldedaten für das Standarddienstkonto Google Cloud APIs aufrufen. Alternativ können Sie Ihr eigenes nutzerverwaltetes Dienstkonto erstellen und es zur Authentifizierung verwenden. Weitere Informationen finden Sie unter Anmeldedaten automatisch finden.

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 project-id@appspot.gserviceaccount.com
Compute Engine und alle Google Cloud-Dienste, die Compute Engine nutzen Standardmäßiges Compute Engine-Dienstkonto project-number-compute@developer.gserviceaccount.com

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. Unter Umständen sehen Sie von Google verwaltete Dienstkonten in der IAM-Richtlinie Ihres Projekts, in Audit-Logs oder auf der IAM-Seite in der Cloud Console.

Von Google verwaltete Dienstkonten werden in der Cloud Console auf der Seite Dienstkonten nicht aufgeführt.

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 project-number@cloudservices.gserviceaccount.com.

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

  • Rollenmanager für von Google verwaltete Dienstkonten: Ihre Audit-Logs für IAM beziehen sich möglicherweise auf das Dienstkonto service-agent-manager@system.gserviceaccount.com.

    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 service-agent-manager@system.gserviceaccount.com 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.

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

Dienstkonto-Standorte

Jedes Dienstkonto befindet sich in einem Projekt. Nachdem Sie ein Dienstkonto erstellt haben, können Sie es nicht in ein anderes Projekt verschieben.

Es gibt verschiedene Möglichkeiten, Ihre Dienstkonten in Projekten zu organisieren:

  • Dienstkonten und Ressourcen im selben Projekt erstellen

    Dieser Ansatz erleichtert Ihnen den Einstieg in Dienstkonten. Es kann jedoch schwierig sein, den Überblick zu behalten, wenn Dienstkonten auf viele Projekte verteilt sind.

  • Dienstkonten in separaten Projekten verwalten

    Bei diesem Ansatz werden alle Dienstkonten für Ihre Organisation in eine kleine Anzahl von Projekten gelegt, was die Verwaltung der Dienstkonten erleichtert. Doch dieser Ansatz erfordert eine zusätzliche Einrichtung, wenn Sie Dienstkonten an Ressourcen in anderen Projekten anhängen. Dadurch können diese Ressourcen das Dienstkonto als Identität verwenden.

    Wenn sich ein Dienstkonto in einem Projekt befindet und auf eine Ressource in einem anderen Projekt zugreift, müssen Sie in der Regel in beiden Projekten die API für diese Ressource aktivieren. Beispiel: Wenn Sie ein Dienstkonto im Projekt my-service-accounts haben und eine Cloud SQL-Instanz im Projekt my-application, müssen Sie die Cloud SQL API in beiden my-service-accounts undmy-application aktivieren.

    Standardmäßig können Sie in einem Projekt bis zu 100 Dienstkonten erstellen. Wenn Sie zusätzliche Dienstkonten erstellen müssen, können Sie eine Kontingenterhöhung anfordern.

Dienstkontoberechtigungen

Dienstkonten sind Identitäten und Ressourcen.

Da es sich bei Dienstkonten um Identitäten handelt, können Sie einem Dienstkonto Zugriff auf Ressourcen in Ihrem Projekt gewähren, indem Sie ihm eine Rolle zuweisen, wie Sie es auch für jedes andere Mitglied tun würden. Wenn Sie beispielsweise dem Dienstkonto Ihrer Anwendung Zugriff auf Objekte in einem Cloud Storage-Bucket gewähren möchten, können Sie dem Dienstkonto die Rolle "Storage-Objekt-Betrachter” (roles/storage.objectViewer) für den Bucket zuweisen.

Dienstkonten sind jedoch auch Ressourcen, die IAM-Richtlinien akzeptieren. Daher können Sie anderen Mitgliedern Zugriff auf ein Dienstkonto gewähren, indem Sie ihnen eine Rolle für das Dienstkonto oder eine der übergeordneten Ressourcen des Dienstkontos zuweisen. Wenn Sie beispielsweise einem Nutzer gestatten möchten, die Identität eines Dienstkontos zu übernehmen, können Sie ihm die Rolle „Dienstkontonutzer” (roles/iam.serviceAccountUser) für das Dienstkonto zuweisen.

Weitere Informationen zum Zuweisen von Rollen für Mitglieder, einschließlich Dienstkonten, finden Sie unter Zugriff gewähren, ändern und entziehen.

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

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.

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.

Zugriffsbereiche

Zugriffsbereiche sind eine Legacy-Methode zum Festlegen von Berechtigungen für eine Compute Engine-VM-Instanz. Sie definieren die standardmäßigen OAuth-Bereiche, die in Anfragen vom gcloud-Tool und Clientbibliotheken verwendet werden.

Google Cloud verwendet jetzt IAM, keine Zugriffsbereiche, um Berechtigungen für Compute Engine-Instanzen anzugeben. Sie müssen dennoch einen Zugriffsbereich festlegen, wenn Sie eine Instanz konfigurieren, um die Identität eines Dienstkontos zu übernehmen.

Weitere Informationen finden Sie in der 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

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 ist ein Tool, mit dem Google Cloud-Clientbibliotheken die Anmeldedaten von Dienstkonten automatisch erkennen. Sie können einen Dienstkontoschlüssel in einer Umgebungsvariablen angeben. Die Standardanmeldedaten für Anwendungen verwenden diesen Dienstkontoschlüssel automatisch. Wenn Sie keinen Schlüssel angeben, verwenden die Standardanmeldedaten für Anwendungen das Dienstkonto, das an die Ressource angehängt ist, die Ihren Code ausführt, oder das Standarddienstkonto für den Dienst, auf dem Ihr Code ausgeführt wird.

Weitere Informationen finden Sie unter Anmeldedaten automatisch finden.

Nächste Schritte

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

Die folgenden Anleitungen enthalten weitere Informationen:

Jetzt testen

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis zu prüfen und zu bewerten. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Jetzt kostenlos starten