Dienstkonten

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 Compute-Arbeitslast verwendet wird, z. B. einer Compute Engine-VM-Instanz. 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.

Beispiel: Ein Dienstkonto kann an eine Compute Engine-VM angehängt werden, sodass sich auf dieser VM ausgeführte Anwendungen als das Dienstkonto authentifizieren können. Darüber hinaus können dem Dienstkonto IAM-Rollen zugewiesen werden, mit denen es auf Ressourcen zugreifen kann. Das Dienstkonto wird als Identität der Anwendung verwendet und die Rollen des Dienstkontos bestimmen, auf welche Ressourcen die Anwendung 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 öffentlich/privaten RSA-Schlüsselpaaren zugeordnet, die zur Authentifizierung bei Google und zum Signieren von Daten 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 Ihre gesamte 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 also weder haben noch verwalten.

Erstellen 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:

Dienstkonten und Google Groups

Sie können einer Google Group Dienstkonten hinzufügen und dann der Gruppe Rollen zuweisen. Das Hinzufügen von Dienstkonten zu Gruppen ist jedoch keine Best Practice. Dienstkonten werden von Anwendungen verwendet und für jede Anwendung gelten wahrscheinlich eigene Zugriffsanforderungen.

Schlüsseltypen für Dienstkonten

Jedes Dienstkonto ist einem öffentlichen/privaten RSA-Schlüsselpaar zugeordnet. Die Service Account Credentials API verwendet dieses interne Schlüsselpaar, um kurzlebige Anmeldedaten für Dienstkonten zu erstellen und Blobs und JSON-Web-Tokens (JWTs) zu signieren. Dieses Schlüsselpaar wird als von Google verwaltetes Schlüsselpaar bezeichnet.

Darüber hinaus können Sie mehrere öffentliche/private RSA-Schlüsselpaare erstellen, die als nutzerverwaltete Schlüsselpaare bezeichnet werden, und den privaten Schlüssel zum Authentifizieren bei Google APIs verwenden. Dieser private Schlüssel wird als Dienstkontoschlüssel bezeichnet.

Von Google verwaltete Schlüsselpaare

Von Google verwaltete Schlüsselpaare werden von der Service Account Credentials API und von Google Cloud-Diensten wie App Engine und Compute Engine verwendet, um kurzlebige Anmeldedaten für Dienstkonten zu generieren.

Von Google verwaltete Schlüsselpaare werden automatisch rotiert und maximal zwei Wochen zum Signieren verwendet. Der Rotationsprozess folgt einem probabilistischen Ansatz. Die Verwendung des neuen Schlüssels wird während der Lebensdauer des Schlüssels schrittweise aufwärts- und abwärtsskaliert.

Der private Schlüssel in einem von Google verwalteten Schlüsselpaar wird immer treuhänderisch aufbewahrt. Sie können nicht direkt darauf zugreifen.

Der öffentliche Schlüssel in einem von Google verwalteten Schlüsselpaar ist öffentlich zugänglich, sodass jeder die mit dem privaten Schlüssel erstellten Signaturen überprüfen kann. Sie können auf den öffentlichen Schlüssel in verschiedenen Formaten zugreifen:

  • X509Certificate: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • JSON-Webschlüssel (JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
  • Rohformat: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Wenn Sie den öffentlichen Schlüssel herunterladen und im Cache speichern, empfehlen wir, ihn für höchstens 24 Stunden im Cache zu speichern, damit Sie immer den aktuellen Schlüssel haben. Unabhängig davon, wann Sie den öffentlichen Schlüssel abrufen, ist er mindestens 24 Stunden nach dem Abruf gültig.

Von Nutzern verwaltete Schlüsselpaare

Sie können von Nutzern verwaltete Schlüsselpaare für ein Dienstkonto erstellen und sich dann mit dem privaten Schlüssel aus jedem Schlüsselpaar bei Google APIs authentifizieren. Dieser private Schlüssel wird als Dienstkontoschlüssel bezeichnet. Jedes Dienstkonto kann bis zu zehn Dienstkontoschlüssel haben. Google speichert nur den öffentlichen Teil eines von Nutzern verwalteten Schlüsselpaars.

Es gibt verschiedene Möglichkeiten, ein nutzerverwaltetes Schlüsselpaar für ein Dienstkonto zu erstellen:

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 Hauptkonten nutzerverwaltete Dienstkontoschlüssel erstellen.
  • constraints/iam.disableServiceAccountKeyUpload: verhindert, dass Hauptkonten 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, der Google Cloud Console oder der Google Cloud CLI 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 Zulassungsrichtlinie 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: Die Zulassungsrichtlinie Ihres Projekts verweist wahrscheinlich auf ein Dienstkonto mit dem Namen des Google APIs-Dienst-Agents 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.

  • Andere Dienst-Agents: Die Zulassungsrichtlinie Ihres Projekts bezieht sich möglicherweise auf andere von Google verwaltete Dienstkonten, die im Namen einzelner Dienste agieren. Diese Dienstkonten werden 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.

  • 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 Zulassungsrichtlinie für das Projekt festgelegt hat.

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 Hauptkonto 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.

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

Dienstkonten sind jedoch auch Ressourcen, die Zulassungsrichtlinien akzeptieren. Daher können Sie anderen Hauptkonten 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 Hauptkonten, 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.

Die Berechtigungen dieser Rolle umfassen die Berechtigung iam.serviceAccounts.actAs. Dadurch können Nutzer, denen die Rolle eines Dienstkontonutzers für ein Dienstkonto zugewiesen wurde, damit indirekt auf alle Ressourcen zugreifen, auf die das Dienstkonto Zugriff hat. Beispiel: Einem Dienstkonto wurde die Rolle eines 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. Bei 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 Zulassungsrichtlinie.
  • 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"

Mit dieser Rolle können Hauptkonten die Identität von Dienstkonten übernehmen, um Folgendes zu tun:

  • OAuth 2.0-Zugriffstokens erstellen, die Sie zur Authentifizierung bei Google APIs verwenden können
  • OIDC-ID-Tokens (OpenID Connect) erstellen
  • JSON Web Tokens (JWTs) und binäre Blobs signieren, damit sie für die Authentifizierung verwendet werden können

Weitere Informationen finden Sie unter Kurzfristige Anmeldedaten für Dienstkonten erstellen.

Die Berechtigungen der Rolle umfassen Folgendes:

  • iam.serviceAccounts.getAccessToken: Ermöglicht das Erstellen von OAuth 2.0-Zugriffstokens
  • iam.serviceAccounts.getOpenIdToken: Ermöglicht das Erstellen von OICD-ID-Tokens (OpenID Connect)
  • iam.serviceAccounts.implicitDelegation: Ermöglicht Dienstkonten, Tokens in einer Delegationskette zu erhalten
  • iam.serviceAccounts.signBlob: Ermöglicht das Signieren binärer Blobs
  • iam.serviceAccounts.signJwt: Ermöglicht das Signieren von JWTs

Rolle "Workload Identity-Nutzer"

Mit dieser Rolle können Hauptkonten die Identität von Dienstkonten von GKE-Arbeitslasten übernehmen.

Die Berechtigungen der Rolle umfassen Folgendes:

  • iam.serviceAccounts.getAccessToken: Ermöglicht das Erstellen von OAuth 2.0-Zugriffstokens
  • iam.serviceAccounts.getOpenIdToken: Ermöglicht das Erstellen von OICD-ID-Tokens (OpenID Connect)

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 von der gcloud CLI 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

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 sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Jetzt kostenlos starten