Details zu Dienstkonten

Hintergrund

Ein Dienstkonto ist eine spezielle Art von Google-Konto, durch das ein nicht menschlicher Nutzer dargestellt wird, der sich für den Zugriff auf Daten in Google APIs authentifizieren muss und dafür autorisiert sein muss.

Dienstkonten werden in der Regel in folgenden Szenarien verwendet:

  • Arbeitslasten auf virtuellen Maschinen (VMs) ausführen
  • Arbeitslasten auf lokalen Workstations oder in Rechenzentren ausführen, die Google APIs aufrufen
  • Arbeitslasten ausführen, die nicht an den Lebenszyklus eines menschlichen Nutzers gebunden sind

Ihre Anwendung nimmt beim Aufrufen der Google APIs die Identität des Dienstkontos an, sodass die Nutzer nicht direkt beteiligt sind.

Dienstkonten verwalten

Wenn Sie entscheiden, dass Sie ein Dienstkonto brauchen, können Sie sich die folgenden Fragen stellen, um zu verstehen, wie Sie das Dienstkonto nutzen werden:

  • Auf welche Ressourcen hat das Dienstkonto Zugriff?
  • Welche Berechtigungen benötigt das Dienstkonto?
  • Wo wird der Code ausgeführt, der die Identität des Dienstkontos annimmt? In der Google Cloud Platform oder lokal?

Finden Sie mithilfe des folgenden Flussdiagramms die Antworten auf diese Fragen:

Flussdiagramm eines Dienstkontos

Dienstkonten können sowohl als Ressource als auch als Identität betrachtet werden.

Wenn Sie das Dienstkonto als Identität ansehen, können Sie ihm eine Rolle zuweisen und ihm somit den Zugriff auf eine Ressource ermöglichen (z. B. ein Projekt).

Wenn Sie ein Dienstkonto als Ressource betrachten, können Sie Nutzern Rollen zuweisen, sodass diese auf das Dienstkonto zugreifen oder es verwalten können.

Zugriff auf Dienstkonten gewähren

Das Gewähren von Zugriff auf ein Dienstkonto, um auf eine Ressource zugreifen zu können, ähnelt dem Gewähren von Zugriff auf eine andere Identität. Angenommen, eine Ihrer Anwendungen wird auf Google Compute Engine ausgeführt und Sie möchten, dass die Anwendung nur dazu berechtigt ist, Objekte in Google Cloud Storage zu erstellen. In diesem Fall können Sie ein Dienstkonto für die Anwendung erstellen und ihm die Rolle Storage-Objekt-Ersteller zuweisen. Das folgende Diagramm zeigt dieses Beispiel:

Flussdiagramm eines Dienstkontos

Weitere Informationen zum Zuweisen von Rollen für alle Mitgliedstypen, einschließlich Dienstkonten.

Dienstkonten verfolgen

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 löschen und neu erstellen

Sie können Dienstkonten löschen und dann ein neues Dienstkonto mit demselben Namen erstellen. Die Wiederverwendung des Namens eines gelöschten Dienstkontos kann ein unerwartetes Verhalten zur Folge haben.

Wenn Sie ein Dienstkonto löschen, werden seine Rollenbindungen nicht sofort gelöscht. Daher hat das neue gleichnamige Dienstkonto möglicherweise noch die alten Bindungen. Sie gelten jedoch für das neue Dienstkonto nicht, obwohl beide Konten dieselbe E-Mail-Adresse haben. Dieses Verhalten ist darin begründet, dass Dienstkonten bei ihrer Erstellung in IAM eine eindeutige ID zugeordnet wird. Über diese ID, nicht über die E-Mail-Adresse des Dienstkontos, werden intern alle Rollenbindungen zugewiesen. Daher gelten die Rollenbindungen des 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, führen Sie die folgenden Schritte aus:

  1. Erstellen Sie das neue Dienstkonto.
  2. Für alle Ressourcen, auf die das neue Dienstkonto zugreifen muss, müssen sämtliche Rollen aufgehoben werden, die dem ursprünglichen Dienstkonto für die jeweiligen Ressourcen zugewiesen wurden.

  3. Nachdem Sie die Rollen des ursprünglichen Dienstkontos widerrufen haben, weisen Sie die Rollen dem neuen Dienstkonto zu.

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.

Berechtigungen für Dienstkonten

In diesem Abschnitt werden häufige Szenarien beschrieben, in denen Dienstkonten Berechtigungen zugewiesen werden oder in denen Nutzerkonten die Berechtigung haben, die Identität von Dienstkonten zu übernehmen:

Dienstkonten geringstmögliche Berechtigungen gewähren

Wie bei allen Mitgliedstypen sollten Sie dem Dienstkonto nur die geringstmöglichen Berechtigungen erteilen, die zum Erreichen seines Ziels erforderlich sind. Weitere Informationen zum Zuweisen von Rollen für alle Mitgliedstypen, einschließlich Dienstkonten.

Wenn Sie Nutzern Berechtigungen für den Zugriff auf ein Dienstkonto gewähren, sollten Sie darauf achten, dass diese auf alle Ressourcen zugreifen können, für die das Dienstkonto Berechtigungen hat. Daher ist es wichtig, dass Sie die Berechtigungen Ihrer Dienstkonten sorgfältig konfigurieren. Sie sollten sich also gut überlegen, welche Ihrer Mitarbeiter mit ihrem Konto wie ein Dienstkonto fungieren oder dessen Identität übernehmen dürfen. Seien Sie besonders vorsichtig, wenn Sie Nutzern erlauben, sich als Nutzer mit stark privilegierten Dienstkonten auszugeben, wie z. B. die Standard-Dienstkonten von Compute Engine und App Engine.

Nutzer mit IAM-Rollen zur Aktualisierung der App Engine- und Compute Engine-Instanzen (z. B. App Engine-Bereitsteller oder Compute-Instanzadministrator) können mit den Dienstkonten, die zur Ausführung dieser Instanzen verwendet werden, effektiv Code ausführen. Außerdem erhalten sie indirekt Zugriff auf alle Ressourcen, auf die diese Dienstkonten Zugriff haben. Entsprechend kann der SSH-Zugriff auf eine Compute Engine-Instanz auch die Möglichkeit bieten, Code als diese Instanz auszuführen.

Dienstkontoberechtigungen für häufige Szenarien

Dienstkonten können in vielen verschiedenen Szenarien verwendet werden, und jedes Szenario erfordert bestimmte Berechtigungen. In diesem Abschnitt werden häufige Szenarien und die jeweils erforderlichen Berechtigungen beschrieben.

Dienstkonten an Ressourcen anhängen

Wenn Sie einen Job mit langer Ausführungszeit starten möchten, der als Dienstkonto authentifiziert wird, müssen Sie der Ressource, die den Job ausführt, ein Dienstkonto hinzufügen.

Berechtigungen:

  • Berechtigungen zum Erstellen der Ressource
  • iam.serviceAccounts.actAs

Suchen Sie in der Rollenliste nach den Berechtigungen, um Rollen zu finden, die diese Berechtigungen enthalten.

Es gibt mehrere verschiedene Google Cloud-Ressourcen, die Jobs mit langer Ausführungszeit als Dienstkonten ausführen können. Beispiele für diese Ressourcen:

  • Compute Engine-VMs
  • App Engine-Apps
  • Cloud Functions

Beim Erstellen dieser Ressourcen können Sie ein Dienstkonto anhängen. Dieses Dienstkonto fungiert als Identität der Ressource.

Um eine Ressource zu erstellen und ein Dienstkonto anzuhängen, benötigen Sie Berechtigungen zum Erstellen dieser Ressource und die Erlaubnis, sich als das Dienstkonto auszugeben, das Sie an die Ressource anhängen werden. Die Berechtigung, die Identität des Dienstkontos zu übernehmen, wird durch jede Rolle gewährt, die die Berechtigung iam.serviceAccounts.actAs enthält.

Nachdem Sie die Ressource erstellt und ein Dienstkonto an sie angehängt haben, können Sie einen Job mit langer Ausführungszeit für die Ressource starten. Der Job wird als das Dienstkonto ausgeführt, das an die Ressource angehängt ist, und verwendet dieses Dienstkonto, um Anfragen an Google Cloud APIs zu autorisieren.

Weitere Informationen zum Anhängen von Dienstkonten an Ressourcen finden Sie unter Dienstkonto an eine Ressource anhängen.

Identität eines Dienstkontos direkt übernehmen

Berechtigungen:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccounts.implicitDelegation

Rollen:

  • roles/iam.serviceAccountTokenCreator (Ersteller von Dienstkonto-Tokens)

Nachdem die erforderlichen Berechtigungen gewährt wurden, kann ein Nutzer oder Dienst in einigen häufigen Szenarien die Identität eines Dienstkontos direkt übernehmen oder bestätigen.

Erstens kann der Nutzer mithilfe der Berechtigung iam.serviceAccounts.getAccessToken und durch Aufrufen der Methode generateAccessToken() Kurzzeitanmeldedaten für das Dienstkonto abrufen. Mithilfe von Kurzzeitanmeldedaten kann ein Nutzer Befehle an Google Cloud senden und auf alle Ressourcen zugreifen, auf die das Dienstkonto Zugriff hat. Mit diesem Ablauf wird es einem Nutzer beispielsweise ermöglicht, die Identität des Dienstkontos mit dem Flag gcloud --impersonate-service-account zu übernehmen, ohne dass ein externer Dienstkontoschlüssel heruntergeladen werden muss.

Zweitens kann der Nutzer Artefakte erhalten, die mit dem von Google verwalteten privaten Schlüssel signiert sind. Dazu nutzt er die Berechtigung iam.serviceAccounts.signBlob und ruft entweder die Methode signBlob() oder die Methode signJwt() auf. Der von Google verwaltete private Schlüssel wird immer treuhänderisch aufbewahrt und ist niemals direkt zugänglich. signBlob() ermöglicht das Signieren beliebiger Nutzlasten (z. B. von Cloud Storage signierte URLs), während signJwt() nur das Signieren korrekt formatierter JWTs zulässt.

Der Nutzer kann auch die Identität des Dienstkontos annehmen oder bestätigen, ohne jemals Anmeldedaten für das Dienstkonto abzurufen. Dies ist ein erweiterter Anwendungsfall und wird nur für den programmatischen Zugriff mit der Methode generateAccessToken() unterstützt. In Szenarien mit mindestens drei Dienstkonten, z. B. A, B und C, kann das Dienstkonto A ein Zugriffstoken für Dienstkonto C erhalten, wenn das Dienstkonto A die Berechtigung iam.serviceAccounts.implicitDelegation für B und das Dienstkonto B die Berechtigung iam.serviceAccounts.getAccessToken für C hat.

OIDC-ID-Tokens (OpenID Connect) generieren

Berechtigungen:

  • iam.serviceAccounts.getOpenIdToken

Rollen:

  • roles/iam.serviceAccountTokenCreator (Ersteller von Dienstkonto-Tokens)

Ein Nutzer oder Dienst kann ein OIDC-kompatibles (OpenID Connect) JWT-Token generieren, das vom Google-OIDC-Anbieter (accounts.google.com) signiert wurde und die Identität des Dienstkontos mithilfe der Berechtigung iam.serviceAccounts.getOpenIdToken darstellt.

Diese Tokens werden von den meisten Google APIs erst akzeptiert, wenn Ihre Organisation ein zusätzliches Identitätsföderationssystem bereitstellt, um Zugriff auf Google zu gewähren. Es gibt jedoch einige Ausnahmen, z. B. den Identity-Aware Proxy, der einen OIDC-basierten Zugriff auf von Nutzern ausgeführte Anwendungen ermöglicht.

Externe private Schlüssel generieren

Berechtigungen:

  • iam.serviceAccountKeys.create

Rollen:

  • roles/editor (Bearbeiter)
  • roles/iam.serviceAccountAdmin (Dienstkontoadministrator)

Ein Nutzer oder Dienst kann externes privates Schlüsselmaterial (RSA) generieren, das zur direkten Authentifizierung bei Google als das Dienstkonto verwendet werden kann. Dieses Schlüsselmaterial kann dann mit ADC-Bibliotheken (Application Default Approximative Credentials) oder mit dem Befehl gcloud auth activate-service-account verwendet werden. Jede Person mit Zugriff auf das Schlüsselmaterial hat dann uneingeschränkten Zugriff auf alle Ressourcen, auf die das Dienstkonto Zugriff hat. Sie sollten mit solchem privaten Schlüsselmaterial sehr sorgfältig umgehen. Betrachten Sie es als weniger sicher, je länger es existiert. Daher ist das Rotieren von privatem Schlüsselmaterial von entscheidender Bedeutung, wenn es darum geht, eine hohe Sicherheit zu gewährleisten.

Dienstkontoschlüssel verwalten

Es gibt zwei Arten von Dienstkontoschlüsseln:

  • GCP-verwaltete Schlüssel: Diese Schlüssel werden von Cloud Platform-Diensten wie App Engine und Compute Engine verwendet. Sie können nicht heruntergeladen werden. Sie 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. Es wird empfohlen, den öffentlichen Schlüsselsatz für ein Dienstkonto höchstens 24 Stunden im Cache zu speichern. Dadurch wird sichergestellt, dass Sie immer auf den aktuellen Schlüsselsatz zugreifen können.

  • Von Nutzern verwaltete Schlüssel: Diese Schlüssel werden von Nutzern erstellt, verwaltet und können von ihnen heruntergeladen werden. Nachdem Sie sie aus dem Dienstkonto gelöscht haben, können sie nicht mehr zur Authentifizierung verwendet werden.

Bei Schlüsseln, die von Nutzern verwaltet werden, müssen Sie prüfen, ob Prozesse vorhanden sind, um Anforderungen an die Schlüsselverwaltung zu erfüllen. Zum Beispiel:

  • Schlüsselspeicherung
  • Schlüsselverteilung
  • Schlüsselwiderruf
  • Schlüsselrotation
  • Schutz des Schlüssels vor unbefugten Nutzern
  • Schlüsselwiederherstellung

Jeder, der Zugriff auf einen gültigen privaten Schlüssel für ein Dienstkonto hat, kann über das Dienstkonto auf Ressourcen zugreifen. Beachten Sie, dass der Lebenszyklus des Schlüsselzugriffs auf das Dienstkonto (und damit die Daten, auf die das Dienstkonto Zugriff hat) vom Lebenszyklus des Nutzers unabhängig ist, der den Schlüssel heruntergeladen hat.

Raten Sie Entwicklern immer davon ab, Schlüssel in den Quellcode aufzunehmen oder sie im Downloadverzeichnis ihrer Workstation zu belassen.

Nachfolgend wird beschrieben, wie Sie die Sicherheit von Schlüsseln verbessern können:

  • Mit der IAM-Dienstkonto-API können Sie Ihre Dienstkontoschlüssel automatisch rotieren. Sie können einen Schlüssel rotieren, indem Sie zuerst einen neuen Schlüssel erstellen, dann die Anwendungen auf den neuen Schlüssel umstellen und anschließend den alten Schlüssel löschen. Verwenden Sie die Methoden serviceAccount.keys.create() und serviceAccount.keys.delete(), um die Rotation zu automatisieren. Die von der GCP verwalteten Schlüssel werden etwa einmal pro Woche rotiert.

Dienstkonten mit Compute Engine verwenden

Compute Engine-Instanzen müssen als Dienstkonten ausgeführt werden, um Zugriff auf andere Cloud Platform-Ressourcen zu haben. So sorgen Sie dafür, dass Ihre Compute Engine-Instanzen sicher sind:

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

  • Sie können Dienstkonten IAM-Rollen zuweisen, um festzulegen, worauf sie Zugriff haben. In vielen Fällen sind für Sie keine Bereiche mehr erforderlich. Dadurch haben Sie die Möglichkeit, die Berechtigungen eines Dienstkontos einer virtuellen Maschine zu ändern, ohne dass Sie die Instanz neu erstellen müssen.

  • Da Instanzen von ihren Dienstkonten abhängig sind, wenn es um den Zugriff auf Cloud Platform-Ressourcen geht, sollten Sie keine Dienstkonten löschen, wenn sie noch von aktiven Instanzen verwendet werden. Wenn Sie die Dienstkonten löschen, kann es sein, dass Funktionen der Instanzen ausfallen.

Best Practices

  • Geben Sie an, wer als Dienstkonto fungieren kann. Nutzer mit der Rolle Dienstkontonutzer für ein bestimmtes Dienstkonto können indirekt auf alle Ressourcen zugreifen, auf die dieses Dienstkonto Zugriff hat. Seien Sie deshalb vorsichtig, wenn Sie einem Nutzer die Rolle "Dienstkontonutzer" zuweisen.

  • Gewähren Sie dem Dienstkonto nur die geringstmöglichen Berechtigungen, die zum Erreichen des Ziels erforderlich sind. Weitere Informationen zum Zuweisen von Rollen für alle Mitgliedstypen, einschließlich Dienstkonten

  • Erstellen Sie Dienstkonten für die einzelnen Dienste nur mit den für diesen Dienst erforderlichen Berechtigungen.

  • Verwenden Sie den Anzeigenamen eines Dienstkontos, um den Überblick über die Dienstkonten zu behalten. Wenn Sie ein Dienstkonto erstellen, fügen Sie als Anzeigenamen die Zielsetzung des Dienstkontos ein.

  • Definieren Sie eine Namenskonvention für Ihre Dienstkonten.

  • Implementieren Sie Prozesse, um die Rotation von Dienstkontoschlüsseln zu automatisieren, die von Nutzern verwaltet werden.

  • Nutzen Sie die IAM Service Account API zum Implementieren der Schlüsselrotation.

  • Sie können Dienstkonten und -schlüssel mithilfe der Methode serviceAccount.keys.list() oder in der Console auf der Seite Loganzeige prüfen.

  • Löschen Sie keine Dienstkonten, die von aktiven Instanzen in App Engine oder Compute Engine genutzt werden, es sei denn, Sie möchten, dass diese Anwendungen den Zugriff auf das Dienstkonto verlieren.