Rollen für die Dienstkontoauthentifizierung

Hauptkonten können Dienstkonten für die Authentifizierung auf verschiedene Arten verwenden. Für jede Art der Authentifizierung muss das Hauptkonto bestimmte IAM-Berechtigungen (Identity and Access Management) für das Dienstkonto haben.

Auf dieser Seite werden die Rollen beschrieben, die Sie Hauptkonten zuweisen können, damit sie die Identität von Dienstkonten übernehmen oder Dienstkonten an Ressourcen anhängen können. Außerdem werden die Berechtigungen beschrieben, die Sie in gängigen Szenarien benötigen.

Weitere Informationen zu den verschiedenen Möglichkeiten, sich mit einem Dienstkonto zu authentifizieren, finden Sie unter Anmeldedaten für Dienstkonten und Dienstkonto-Identitätsübernahme.

Dienstkontorollen

In diesem Abschnitt werden die Rollen beschrieben, mit denen sich Hauptkonten mit Dienstkonten authentifizieren können. Informationen zum Zuweisen und Widerrufen dieser Rollen finden Sie unter Zugriff auf Dienstkonten verwalten.

Rolle "Dienstkontonutzer"

Mit der Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser) kann ein Hauptkonto ein Dienstkonto an eine Ressource anhängen. Wenn der auf dieser Ressource ausgeführte Code authentifiziert werden muss, kann er Anmeldedaten für das angehängte Dienstkonto abrufen.

Mit dieser Rolle erhalten Hauptkonten nicht die Berechtigung, kurzlebige Anmeldedaten für Dienstkonten zu erstellen oder das Flag --impersonate-service-account für die Google Cloud CLI zu verwenden. Zum Ausführen dieser Aufgaben benötigen Sie die Rolle Ersteller von Dienstkonto-Tokens für das Dienstkonto.

Rolle "Dienstkonto-Token-Ersteller"

Mit der Rolle „Ersteller von Dienstkonto-Tokens“ (roles/iam.serviceAccountTokenCreator) können Hauptkonten kurzlebige Anmeldedaten für ein Dienstkonto erstellen.

Mit der Rolle „Ersteller von Dienstkonto-Tokens“ können Sie folgende Arten von kurzlebigen Anmeldedaten erstellen:

• OAuth 2.0-Zugriffstokens erstellen, die Sie zur Authentifizierung bei Google APIs verwenden können
• OIDC-ID-Tokens (OpenID Connect)
• Signierte JSON-Web-Tokens (JWTs) und binäre Blobs.

Mit der Rolle „Ersteller von Dienstkonto-Tokens“ können Hauptkonten auch das Flag --impersonate-service-account für die gcloud CLI verwenden. Wenn Sie dieses Flag verwenden, erstellt die gcloud CLI automatisch kurzlebige Anmeldedaten für das Dienstkonto.

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

Ersteller des OpenID Connect-Identitätstokens für das Dienstkonto

Mit der Rolle „Ersteller des OpenID Connect-Identitätstokens für das Dienstkonto“ (roles/iam.serviceAccountOpenIdTokenCreator) können Hauptkonten kurzlebige OIDC-ID-Tokens erstellen. Wenn Sie nur OIDC-ID-Tokens erstellen müssen, verwenden Sie diese Rolle. Wenn Sie andere Arten von Tokens erstellen müssen, verwenden Sie stattdessen die Rolle „Ersteller von Dienstkonto-Tokens“.

Die Rolle enthält die Berechtigung iam.serviceAccounts.getOpenIdToken, mit der Sie ein OIDC-ID-Token erstellen können.

Workload Identity-Nutzerrolle

Mit der Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) 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 OIDC-ID-Tokens (OpenID Connect)

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

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, das Dienstkonto an Ressourcen anzuhängen. Berechtigung zum Anhängen von Dienstkonten an Ressourcen, die durch jede Rolle gewährt wird, die die Berechtigung iam.serviceAccounts.actAs enthält, z. B. die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser).

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.

Zuerst kann sich der Nutzer als Dienstkonto authentifizieren. Sie können zum Beispiel kurzlebige Anmeldedaten für das Dienstkonto mit der Berechtigung iam.serviceAccounts.getAccessToken und durch den Aufruf der Methode generateAccessToken() erhalten. Alternativ kann er das Flag --impersonate-service-account für die gcloud CLI verwenden, um die Identität des Dienstkontos zu übernehmen. Wenn sich ein Nutzer als Dienstkonto authentifiziert, kann er Befehle an Google Cloud senden und auf alle Ressourcen zugreifen, auf die das Dienstkonto Zugriff hat.

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, 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 B die Berechtigung iam.serviceAccounts.getAccessToken für C hat.

OIDC-ID-Tokens (OpenID Connect) generieren

Berechtigungen:

• iam.serviceAccounts.getOpenIdToken

Rollen:

• roles/iam.serviceAccountOpenIdTokenCreator (Ersteller des OpenID Connect-Identitätstokens für das Dienstkonto)

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.serviceAccountKeyAdmin (Zentraler 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.

Dienstkontoberechtigungen, die andere Funktionen ermöglichen

Einige Berechtigungen für Anmeldedaten von Dienstkonten ermöglichen mehrere Funktionen. Mit iam.serviceAccounts.signBlob und iam.serviceAccounts.signJwt können Hauptkonten beispielsweise auch Zugriffs- und Identitätstokens für ein Dienstkonto generieren. Da mit iam.serviceAccounts.signBlob Hauptkonten jede Art von Daten signieren können, können sie auch JWTs signieren.

Bevor Sie benutzerdefinierten Rollen eine dieser Berechtigungen hinzufügen, sollten Sie wissen, welche Aktionen mit den einzelnen Berechtigungen möglich sind.

In der folgenden Tabelle sind die Vorgänge aufgeführt, die durch diese Berechtigungen aktiviert werden:

Best Practices für die Zuweisung von Rollen für Dienstkonten

Hinweis: In Szenarien, in denen einem Dienstkonto Berechtigungen zum Ausführen von Vorgängen mit umfangreichen Rechten gewährt wurden, sollten Sie vorsichtig sein, wenn Sie einem Nutzer die Rolle „Dienstkontonutzer“ oder die zugehörigen Berechtigungen für dieses Dienstkonto zuweisen.

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 Dienstkontoschlü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 für Ihre Dienstkonten keine Dienstkontoschlüssel erforderlich sind, deaktivieren oder löschen Sie sie.
• Wenn Nutzer keine Berechtigung zum Verwalten oder Verwenden von Dienstkonten benötigen, entfernen Sie sie aus der entsprechenden Zulassungsrichtlinie.
• Informationen dazu, wie Sie durch das Gewähren bestimmter Berechtigungen für Dienstkonten andere Funktionen effektiv aktivieren können.
• 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 Best Practices für die Arbeit mit Dienstkonten.