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

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 in Compute Engine ausgeführt und Sie möchten, dass die Anwendung nur dazu berechtigt ist, Objekte in 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.

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.

Nicht verwendete Dienstkonten identifizieren

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.

Dienstkonten löschen und 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 Mitgliedern.

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

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 Aufruf 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. Identity-Aware Proxy, das 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:

  • Von Google Cloud verwaltete Schlüssel: Diese Schlüssel werden von Google Cloud-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 Service Account API können Sie Ihre Dienstkontoschlüssel automatisch rotieren. Zum Rotieren eines Schlüssels erstellen Sie zuerst einen neuen Schlüssel, stellen Anwendungen auf den neuen Schlüssel um und löschen anschließend den alten Schlüssel. Verwenden Sie die Methoden serviceAccount.keys.create() und serviceAccount.keys.delete() zusammen, um die Rotation zu automatisieren. Die von Google Cloud 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 Google Cloud-Ressourcen zu haben. So sorgen Sie dafür, dass die Sicherheit Ihrer Compute Engine-Instanzen erhöht wird:

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

  • 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. Wenn Sie die Dienstkonten löschen, kann es sein, dass Vorgänge der Instanzen fehlschlagen.

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