Dienstkonten – Übersicht

Auf dieser Seite werden Dienstkonten erläutert und wichtige Überlegungen zur Verwaltung Ihrer Dienstkonten in jeder Phase ihres Lebenszyklus beschrieben.

Was sind Dienstkonten?

Ein Dienstkonto ist eine spezielle Art von Konto, das normalerweise von einer Anwendung oder einer Compute-Arbeitslast verwendet wird, z. B. eine Compute Engine-Instanz und keine Person. Ein Dienstkonto wird durch seine E-Mail-Adresse definiert, die für das Konto spezifisch ist.

Anwendungen verwenden Dienstkonten für autorisierte API-Aufrufe, die als Dienstkonto selbst oder als Google Workspace- oder Cloud Identity-Nutzer mithilfe domainweiter Delegation authentifiziert werden. Wenn sich eine Anwendung als Dienstkonto authentifiziert, hat sie Zugriff auf alle Ressourcen, auf die das Dienstkonto Zugriff hat.

Die gängigste Methode, um einer Anwendung die Authentifizierung als Dienstkonto zu ermöglichen, besteht darin, ein Dienstkonto an die Ressource anzuhängen, auf der die Anwendung ausgeführt wird. Sie können beispielsweise ein Dienstkonto an eine Compute Engine-Instanz anhängen, damit sich Anwendungen, die auf dieser Instanz ausgeführt werden, als das Dienstkonto authentifizieren können. Anschließend können Sie dem Dienstkonto IAM-Rollen zuweisen, damit das Dienstkonto – und daher Anwendungen auf der Instanz – auf Google Cloud-Ressourcen zugreifen können.

Neben dem Anhängen eines Dienstkontos gibt es noch andere Möglichkeiten, Anwendungen die Authentifizierung als Dienstkonten zu ermöglichen. Sie können beispielsweise die Identitätsföderation von Arbeitslasten einrichten, damit sich externe Arbeitslasten als Dienstkonten authentifizieren können, oder einen Dienstkontoschlüssel erstellen. Verwenden Sie es ihn einer beliebigen Umgebung, um OAuth 2.0-Zugriffstoken abzurufen.

Weitere Informationen zur Dienstkontoauthentifizierung für Anwendungen finden Sie unter Identitäten für Arbeitslasten.

Hauptkonten wie Nutzer und andere Dienstkonten können sich auch als Dienstkonten authentifizieren. Weitere Informationen finden Sie unter Dienstkonto-Identitätsübernahme auf dieser Seite.

Arten von Dienstkonten

In Google Cloud gibt es verschiedene Arten von Dienstkonten:

  • Nutzerverwaltete Dienstkonten: Dienstkonten, die Sie erstellen und verwalten. Diese Dienstkonten werden häufig als Identitäten für Arbeitslasten verwendet.

  • Standarddienstkonten: Nutzerverwaltete Dienstkonten, die automatisch erstellt werden, wenn Sie bestimmte Google Cloud-Dienste aktivieren. Sie sind für die Verwaltung dieser Dienstkonten verantwortlich.

  • Von Google verwaltete Dienstkonten: Von Google erstellte und von Google verwaltete Dienstkonten, mit denen Dienste in Ihrem Namen auf Ressourcen zugreifen können.

Weitere Informationen zu den verschiedenen Arten von Dienstkonten finden Sie unter Arten von Dienstkonten.

Dienstkonto-Anmeldedaten

Anwendungen und Hauptkonten authentifizieren sich als Dienstkonto. Dazu haben sie folgende Möglichkeiten:

  • Rufen Sie kurzlebige Anmeldedaten ab. In vielen Fällen, z. B. bei angehängten Dienstkonten und Befehlen mit dem Flag --impersonate-service-account der gcloud CLI, werden diese Anmeldedaten automatisch abgerufen. Sie müssen sie nicht selbst erstellen oder verwalten.
  • Mit einem Dienstkontoschlüssel ein JSON Web Token (JWT) signieren und gegen ein Zugriffstoken austauschen Da Dienstkontoschlüssel ein Sicherheitsrisiko darstellen, wenn sie nicht ordnungsgemäß verwaltet werden, sollten Sie nach Möglichkeit eine sicherere Alternative zu Dienstkontoschlüsseln auswählen.

Weitere Informationen zur Dienstkontoauthentifizierung finden Sie unter Anmeldedaten des Dienstkontos.

Identitätsübertragung für ein Dienstkonto

Wenn sich ein authentifiziertes Hauptkonto, z. B. ein Nutzer oder ein anderes Dienstkonto, als ein Dienstkonto authentifiziert, um die Berechtigungen des Dienstkontos zu erhalten, wird dies als Identitätsübernahme des Dienstkontos bezeichnet. Wenn Sie die Identität eines Dienstkontos übernehmen, kann ein authentifiziertes Hauptkonto auf alles zugreifen, auf das das Dienstkonto zugreifen kann. Nur authentifizierte Hauptkonten mit den entsprechenden Berechtigungen können die Identität von Dienstkonten übernehmen.

Die Identitätsübernahme ist nützlich, wenn Sie die Berechtigungen eines Nutzers ändern möchten, ohne Ihre IAM-Richtlinien (Identity and Access Management) zu ändern. So können Sie beispielsweise die Identitätsübernahme verwenden, um einem Nutzer vorübergehend erweiterten Zugriff zu gewähren oder um zu testen, ob ein bestimmter Satz von Berechtigungen für eine Aufgabe ausreichend ist. Sie können die Identitätsübernahme auch verwenden, um Anwendungen lokal zu entwickeln, die nur als Dienstkonto ausgeführt werden können, oder um Anwendungen zu authentifizieren, die außerhalb von Google Cloud ausgeführt werden.

Weitere Informationen zur Übernahme der Identität von Dienstkonten finden Sie unter Identitätsübernahme des Dienstkontos.

Dienstkonten und Google Workspace-Domains

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.

Dienstkontoberechtigungen

Dienstkonten sind Hauptkonten. Dies bedeutet, dass Sie Dienstkonten Zugriff auf Google Cloud-Ressourcen gewähren können. Beispielsweise können Sie einem Dienstkonto für ein Projekt die Rolle „Compute-Administrator” (roles/compute.admin) zuweisen. Dann könnte das Dienstkonto Compute Engine-Ressourcen in diesem Projekt verwalten.

Dienstkonten sind jedoch auch Ressourcen. Dies bedeutet, dass Sie anderen Hauptkonten die Berechtigung erteilen können, auf das Dienstkonto zuzugreifen. Beispielsweise können Sie einem Nutzer die Rolle "Dienstkontonutzer" (roles/iam.serviceAccountUser) für ein Dienstkonto zuweisen, damit der Nutzer dieses Dienstkonto an Ressourcen anhängen kann. Alternativ können Sie einem Nutzer die Rolle "Dienstkontoadministrator" (roles/iam.serviceAccountAdmin) zuweisen, damit er Aufgaben wie das Aufrufen, Bearbeiten, Deaktivieren und Löschen des Dienstkontos ausführen kann.

In den folgenden Abschnitten wird erläutert, wie Sie Dienstkonten als Hauptkonten und als Ressourcen verwalten.

Dienstkonten als Hauptkonten

Da es sich bei Dienstkonten um Hauptkonten 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.

Wie bei allen Hauptkontotypen sollten Sie dem Dienstkonto nur die geringstmöglichen Berechtigungen erteilen, die zum Erreichen seines Ziels erforderlich sind.

Wie bei anderen Hauptkonten können Sie einer Google-Gruppe 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.

Informationen zum Zuweisen von Rollen für Hauptkonten, einschließlich Dienstkonten, finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Dienstkonten als Ressourcen

Dienstkonten sind auch Ressourcen, die eigene Zulassungsrichtlinien haben können. 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 „Ersteller von Dienstkonto-Tokens” (roles/iam.serviceAccountTokenCreator) für das Dienstkonto zuweisen.

Beachten Sie, dass beim Zuweisen einer Rolle, mit der ein Nutzer die Identität eines Dienstkontos übernehmen kann, der Nutzer auf alle Ressourcen zugreifen kann, auf die das Dienstkonto zugreifen kann. Seien Sie vorsichtig, wenn Sie Nutzern erlauben, sich als Nutzer mit stark privilegierten Dienstkonten auszugeben, wie z. B. die Standarddienstkonten von Compute Engine und App Engine.

Weitere Informationen zu den Rollen, die Sie Hauptkonten für Dienstkonten zuweisen können, finden Sie unter Dienstkontoberechtigungen.

Informationen zum Zuweisen der Rolle eines Hauptkontos für ein Dienstkonto finden Sie unter Zugriff auf Dienstkonten verwalten.

Lebenszyklus eines Dienstkontos

Bei der Verwaltung Ihrer Projekte werden Sie wahrscheinlich viele verschiedene Dienstkonten erstellen, verwalten und löschen. In diesem Abschnitt werden wichtige Überlegungen zur Verwaltung Ihrer Dienstkonten in den verschiedenen Lebenszyklusphasen beschrieben.

Wo Sie Dienstkonten erstellen

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.

Informationen zum Erstellen eines Dienstkontos finden Sie unter Dienstkonten erstellen.

Erstellen von Dienstkonten verhindern

Um besser steuern zu können, wo Dienstkonten erstellt werden, möchten Sie möglicherweise verhindern, dass Dienstkonten in einigen Projekten Ihrer Organisation erstellt werden.

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:

  • Wenn Sie diese Einschränkung in einem Projekt oder in allen Projekten innerhalb einer Organisation erzwingen, können einige Google Cloud-Dienste keine Standarddienstkonten erstellen. Wenn das Projekt Arbeitslasten ausführt, für die eine Authentifizierung des Dienstkontos erforderlich ist, enthält das Projekt möglicherweise kein Dienstkonto, das von der Arbeitslast verwendet werden kann.

    Zur Behebung dieses Problems können Sie den Identitätswechsel zwischen Dienstkonten über Projekte hinweg aktivieren. Wenn Sie dieses Feature aktivieren, können Sie Dienstkonten in einem zentralisierten Projekt erstellen und diese Dienstkonten dann an Ressourcen in anderen Projekten anhängen. Arbeitslasten, die auf diesen Ressourcen ausgeführt werden, können sich über die angehängten Dienstkonten authentifizieren. Dadurch sind die Standarddienstkonten nicht erforderlich.

  • Bei einigen Funktionen, darunter Identitätsföderation von Arbeitslasten, müssen Dienstkonten erstellt werden.

    Wenn Sie die Workload Identity Federation nicht verwenden, empfiehlt es sich, mit Organisationsrichtlinieneinschränkungen die Föderation von allen Identitätsanbietern zu blockieren.

Dienstkonten im Blick behalten

Wenn Sie mit der Zeit immer mehr Dienstkonten erstellen, verlieren Sie unter Umständen den Überblick, welches Dienstkonto zu welchem Zweck verwendet wird.

Der Anzeigename eines Dienstkontos ist eine gute Möglichkeit, weitere Informationen zu dem Dienstkonto zu erfassen, zum Beispiel den Zweck des Dienstkontos oder eine Kontaktperson für das Konto. Bei neuen Dienstkonten können Sie den Anzeigenamen eingeben, wenn Sie das Dienstkonto erstellen. Verwenden Sie für vorhandene Dienstkonten die Methode serviceAccounts.update(), um den Anzeigenamen zu ändern.

Dienstkonten mit Compute Engine verwenden

Compute Engine-Instanzen müssen als Dienstkonten ausgeführt werden, um Zugriff auf andere Google Cloud-Ressourcen zu haben. Beachten Sie zum Schutz Ihrer Compute Engine-Instanzen Folgendes:

  • Sie können Instanzen in einem Projekt mit unterschiedlichen Dienstkonten erstellen. Mit der Methode instances.setServiceAccount können Sie das Dienstkonto einer Instanz nach dem Erstellen ändern.

  • Um die Autorisierung für angehängte Dienstkonten einzurichten, müssen Sie zusätzlich zur Konfiguration von IAM-Rollen Zugriffsbereiche konfigurieren.

  • Instanzen sind von ihren Dienstkonten abhängig. Löschen Sie also keine Dienstkonten, die noch von aktiven Instanzen verwendet werden, um den Zugriff auf Google Cloud-Ressourcen nicht zu verlieren.

Weitere Informationen zur Verwendung von Dienstkonten mit Compute Engine finden Sie in der Compute Engine-Dokumentation unter Dienstkonten.

Nicht verwendete Dienstkonten identifizieren

Nach einiger Zeit haben Sie möglicherweise Dienstkonten in Ihren Projekten, die Sie nicht mehr verwenden.

Nicht verwendete Dienstkonten stellen ein unnötiges Sicherheitsrisiko dar. Wir empfehlen daher, nicht verwendete Dienstkonten zu deaktivieren und die Dienstkonten dann zu löschen, wenn Sie sich sicher sind, dass Sie sie nicht mehr benötigen. Mit den folgenden Methoden können Sie nicht verwendete Dienstkonten identifizieren:

  • Dienstkontostatistiken zeigen Ihnen, für welche Dienstkonten in den letzten 90 Tagen keine Authentifizierung durchgeführt wurde.
  • Mit dem Aktivitätsanalysetool können Sie prüfen, wann ein Dienstkonto oder Schlüssel zuletzt verwendet wurde.

Sie können auch Messwerte zur Dienstkontonutzung verwenden, um die Dienstkonto- und Schlüsselnutzung allgemein zu verfolgen.

Wenn Sie ein Security Command Center Premium-Kunde sind, können Sie mit Event Threat Detection eine Benachrichtigung erhalten, wenn ein inaktives Dienstkonto eine Aktion auslöst. Inaktive Dienstkonten sind Dienstkonten, die seit mehr als 180 Tagen inaktiv sind. Nachdem ein Dienstkonto verwendet wurde, ist es nicht mehr inaktiv.

Dienstkonten löschen

Bevor Sie ein Dienstkonto löschen, deaktivieren Sie das Dienstkonto, um sicherzustellen, dass es nicht mehr erforderlich ist. Deaktivierte Dienstkonten können wieder aktiviert werden, wenn sie noch verwendet werden.

Nachdem Sie bestätigt haben, dass ein Dienstkonto nicht erforderlich ist, können Sie das Dienstkonto löschen.

Gelöschte Dienstkonten neu erstellen

Sie können Dienstkonten löschen und dann ein neues Dienstkonto mit demselben Namen erstellen.

Wenn Sie ein Dienstkonto löschen, werden seine Rollenbindungen nicht sofort gelöscht. Stattdessen wird das Dienstkonto in den Rollenbindungen mit dem Präfix deleted: aufgelistet. Ein Beispiel finden Sie unter Richtlinien mit gelöschten Hauptkonten.

Daher hat das neue gleichnamige Dienstkonto möglicherweise noch die alten Bindungen. Sie gelten jedoch nicht für das neue Dienstkonto, obwohl beide Konten dieselbe E-Mail-Adresse haben. Dieses Verhalten ist darin begründet, dass Dienstkonten bei ihrer Erstellung eine eindeutige ID in Identity and Access Management (IAM) zugewiesen wird. Über diese ID, nicht über die E-Mail-Adresse des Dienstkontos, werden intern alle Rollenbindungen zugewiesen. Daher gelten die Rollenbindungen eines gelöschten Dienstkontos nicht für neue Dienstkonten, die dieselbe E-Mail-Adresse verwenden.

Wenn Sie beispielsweise ein Dienstkonto an eine Ressource anhängen, löschen Sie dann das Dienstkonto und erstellen ein neues Dienstkonto mit demselben Namen. Das neue Dienstkonto wird nicht an die Ressource angehängt werden.

Um dieses unerwartete Verhalten zu vermeiden, sollten Sie einen neuen, eindeutigen Namen für jedes Dienstkonto verwenden. Wenn Sie ein Dienstkonto versehentlich gelöscht haben, können Sie versuchen, das Dienstkonto wiederherzustellen, anstatt ein neues Dienstkonto zu erstellen.

Wenn Sie das ursprüngliche Dienstkonto nicht wiederherstellen können und ein neues Dienstkonto mit demselben Namen und denselben Rollen erstellen müssen, müssen Sie dem neuen Dienstkonto die Rollen zuweisen. Weitere Informationen finden Sie unter Richtlinien mit gelöschten Hauptkonten.

Führen Sie einen der folgenden Schritte aus, wenn das neue Dienstkonto ebenfalls an dieselben Ressourcen wie das ursprüngliche Dienstkonto angehängt werden soll.

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