Auf dieser Seite werden Dienstkonten, Arten von Dienstkonten und die IAM-Rollen beschrieben, die für Dienstkonten verfügbar sind.
Hinweis
- Sie sollten die grundlegenden Konzepte von IAM verstehen.
Was sind Dienstkonten?
Ein Dienstkonto ist ein spezieller Kontotyp, der nicht von einer Person, sondern von einer Anwendung oder einer VM-Instanz verwendet wird. Anwendungen verwenden Dienstkonten für autorisierte API-Aufrufe, die als Dienstkonto selbst oder als G Suite- oder Cloud Identity-Nutzer mithilfe domainweiter Delegation autorisiert werden.
Eine Compute Engine-VM kann beispielsweise als Dienstkonto ausgeführt werden, dem Berechtigungen für den Zugriff auf benötigte Ressourcen zugewiesen sind. Damit ist das Dienstkonto die Identität des Dienstes und die Berechtigungen des Dienstkontos bestimmen, auf welche Ressourcen der Dienst 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 privaten und öffentlichen RSA-Schlüsselpaaren zugeordnet, die zur Authentifizierung bei Google verwendet werden.
- Es können IAM-Berechtigungen erteilt werden, damit andere Nutzer oder andere Dienstkonten die Möglichkeit haben, die Identität eines Dienstkontos zu übernehmen.
- Dienstkonten gehören im Gegensatz zu Nutzerkonten nicht zu Ihrer G Suite-Domain. Wenn Sie beispielsweise Inhalte mit den Mitgliedern Ihrer G Suite-Domain teilen, werden diese nicht für Dienstkonten freigegeben. Ebenso können G Suite- oder Cloud Identity-Administratoren nicht Inhaber der von einem Dienstkonto erstellten Inhalte sein und diese nicht verwalten. Dies gilt nicht für die Verwendung der domainweiten Delegierung, da API-Aufrufe als imitierter Nutzer autorisiert werden, nicht als das Dienstkonto selbst.
Dienstkontoschlüssel
Jedem Dienstkonto sind zwei Sätze öffentlicher/privater RSA-Schlüsselpaare zugeordnet, die zur Authentifizierung bei Google verwendet werden: von Google verwaltete Schlüssel und vom Nutzer verwaltete Schlüssel.
Von Google verwaltete Schlüssel
Bei von Google verwalteten Schlüsselpaaren speichert Google sowohl den öffentlichen als auch den privaten Teil des Schlüssels und rotiert die Paare regelmäßig. Jeder Schlüssel kann maximal zwei Wochen lang zum Signieren verwendet werden. Der private Schlüssel wird immer treuhänderisch aufbewahrt und ist niemals direkt zugänglich. IAM stellt APIs bereit, um diese Schlüssel für die Anmeldung im Namen des Dienstkontos zu verwenden. Weitere Informationen finden Sie unter Kurzlebige Anmeldedaten für Dienstkonten erstellen.
Nutzerverwaltete Schlüssel
Nutzerverwaltete Schlüsselpaare implizieren, dass Sie sowohl den öffentlichen als auch den privaten Teil eines Schlüsselpaars haben. Sie können ein oder mehrere nutzerverwaltete Schlüsselpaare erstellen (sogenannte "externe" Schlüssel), die auch außerhalb von Google Cloud verwendet werden können. Google speichert nur den öffentlichen Teil eines nutzerverwalteten Schlüssels.
Außerdem können Sie einen öffentlichen Schlüssel im entsprechenden Format erstellen und in Google hochladen. Dort wird er dauerhaft mit dem angegebenen Dienstkonto verknüpft. Wenn Sie Signiervorgänge für dieses Dienstkonto ausführen müssen, z. B. beim Erstellen von Dienstkontoschlüsseln, wird dafür der hochgeladene öffentliche Schlüssel verwendet.
Der private Teil eines nutzerverwalteten Schlüsselpaars wird im Allgemeinen mit Standardanmeldedaten für Anwendungen verwendet. Der private Schlüssel wird dann zur Authentifizierung von Server-zu-Server-Anwendungen verwendet.
Bei nutzerverwalteten Schlüsseln sind Sie für die Sicherheit des privaten Schlüssels und andere Verwaltungsvorgänge wie die Schlüsselrotation verantwortlich. Nutzerverwaltete Schlüssel können über die IAM API, mit dem gcloud-Befehlszeilentool oder in der Google Cloud Console auf der Seite "Dienstkonten" verwaltet werden. Sie können bis zu 10 Dienstkontoschlüssel pro Dienstkonto erstellen, um eine Schlüsselrotation zu ermöglichen.
Sie können den Cloud Key Management Service (Cloud KMS) verwenden, um Schlüssel sicher zu verwalten.
Von Nutzern verwaltete Schlüssel eingeschränkt nutzen
Von Nutzern verwaltete Schlüssel sind äußerst leistungsstarke Anmeldedaten und können ein Sicherheitsrisiko darstellen, wenn sie nicht ordnungsgemäß verwaltet werden.
Sie können die Nutzung einschränken. Dazu wenden Sie die Beschränkung für Organisationsrichtlinien constraints/iam.disableServiceAccountKeyCreation auf Projekte, Ordner oder sogar auf Ihre gesamte Organisation an. Nach der Anwendung der Beschränkung können Sie nutzerverwaltete Schlüssel in kontrollierten Umgebungen aktivieren und so das potenzielle Risiko minimieren, das nicht verwaltete Schlüssel verursachen.
Arten von Dienstkonten
Nutzerverwaltete Dienstkonten
Sie können in Ihrem Projekt nutzerverwaltete Dienstkonten mit der IAM API, mit der Cloud Console oder mit dem gcloud-Befehlszeilentool 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.
Die Standarddienstkonten erleichtern den Einstieg in Google Cloud-Dienste. Für Produktionsarbeitslasten empfehlen wir dringend, eigene nutzerverwaltete Dienstkonten zu erstellen und jedem Dienstkonto die entsprechenden Rollen zuzuweisen.
Wenn ein Standarddienstkonto erstellt wird, erhält es automatisch die Rolle "Bearbeiter" (roles/editor) für Ihr Projekt. Diese Rolle umfasst eine Vielzahl von Berechtigungen. Zur Beachtung des Prinzips der geringsten Berechtigung empfehlen wir dringend, die automatische Rollenzuweisung zu deaktivieren. Dazu fügen Sie Ihrer Organisationsrichtlinie eine Einschränkung hinzu oder widerrufen die Bearbeiterrolle manuell. Wenn Sie die Rollenzuweisung deaktivieren oder widerrufen, müssen Sie festlegen, welche Rollen den Standarddienstkonten zugeteilt werden sollen.
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 | Compute Engine-Standarddienstkonto |
project-number-compute@developer.gserviceaccount.com
|
Von Google verwaltete Dienstkonten
Neben den von Nutzern verwalteten Dienstkonten und Standarddienstkonten werden Ihnen in der IAM-Richtlinie Ihres Projekts, in der Cloud Console und in den Audit-Logs möglicherweise weitere Dienstkonten angezeigt. Diese Dienstkonten werden von Google erstellt und verwaltet und von Google-Diensten verwendet.
Der angezeigte Name der meisten von Google verwalteten Dienstkonten endet mit "Service Agent" oder "Service Account". Einige dieser Dienstkonten sind sichtbar, andere sind ausgeblendet.
Beispiel:
Google APIs-Dienst-Agent: Ihr Projekt enthält wahrscheinlich ein Dienstkonto namens Google APIs-Dienst-Agent 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.Rollenmanager für von Google verwaltete Dienstkonten: Ihre Audit-Logs für IAM beziehen sich möglicherweise auf das Dienstkonto
one-platform-tenant-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
one-platform-tenant-manager@system.gserviceaccount.comdie IAM-Richtlinie für das Projekt festgelegt hat.Andere von Google verwaltete Dienstkonten: Möglicherweise werden anderen von Google verwalteten Dienstkonten im Projekt automatisch Rollen zugewiesen. Die Namen dieser Rollen enden normalerweise auf
serviceAgent.
In der folgenden Tabelle sind einige der von Google verwalteten Dienstkonten aufgeführt, die in Ihrem Projekt neben dem Google APIs-Dienst-Agent und dem Rollenmanager vorhanden sein können. Außerdem wird das Format der E-Mail-Adresse für jedes dieser Dienstkonten angezeigt. Ersetzen Sie project-number durch die Projektnummer. Sie finden die Projektnummer im Cloud Console-Dashboard Ihres Projekts.
| Von Google verwaltete Dienstkonten | |
|---|---|
| Artifact Registry-Dienstkonto | service-project-number@gcp-sa-artifactregistry.iam.gserviceaccount.com |
| BigQuery Data Transfer-Dienst-Agent | service-project-number@gcp-sa-bigquerydatatransfer.iam.gserviceaccount.com |
| Cloud AI Platform Notebooks-Dienstkonto | service-project-number@gcp-sa-notebooks.iam.gserviceaccount.com |
| Cloud Composer-Dienst-Agent | service-project-number@cloudcomposer-accounts.iam.gserviceaccount.com |
| Cloud Data Fusion-Dienstkonto | service-project-number@gcp-sa-datafusion.iam.gserviceaccount.com |
| Cloud Dataflow-Dienstkonto | service-project-number@dataflow-service-producer-prod.iam.gserviceaccount.com |
| Cloud Life Sciences-Dienst-Agent | service-project-number@gcp-sa-lifesciences.iam.gserviceaccount.com |
| Cloud Pub/Sub-Dienstkonto | service-project-number@gcp-sa-pubsub.iam.gserviceaccount.com |
| Cloud Scheduler-Dienstkonto | service-project-number@gcp-sa-cloudscheduler.iam.gserviceaccount.com |
| Dienst-Agent für Cloud Source Repositories | service-project-number@sourcerepo-service-accounts.iam.gserviceaccount.com |
| Compute Engine-Dienst-Agent | service-project-number@compute-system.iam.gserviceaccount.com |
| Google Cloud Dataproc-Dienst-Agent | service-project-number@dataproc-accounts.iam.gserviceaccount.com |
| Google Cloud Functions-Dienst-Agent | service-project-number@gcf-admin-robot.iam.gserviceaccount.com |
| Google Cloud ML Engine-Dienst-Agent | service-project-number@cloud-ml.google.com.iam.gserviceaccount.com |
| Google Cloud Run-Dienst-Agent | service-project-number@serverless-robot-prod.iam.gserviceaccount.com |
| Kubernetes Engine-Dienst-Agent | service-project-number@container-engine-robot.iam.gserviceaccount.com |
| TPU-Dienst-Agent | service-project-number@cloud-tpu.iam.gserviceaccount.com |
Dienstkontoberechtigungen
Ein Dienstkonto ist nicht nur eine Identität, sondern auch eine Ressource, der IAM-Richtlinien zugewiesen sind. Durch diese Richtlinien wird bestimmt, wer das Dienstkonto nutzen kann.
Alice kann beispielsweise die Bearbeiterrolle und Bob die Betrachterrolle für ein Dienstkonto haben. Dies entspricht dem Zuweisen von Rollen für andere Google Cloud-Ressourcen.
Den standardmäßigen Compute Engine- und App Engine-Dienstkonten werden Bearbeiterrollen für das Projekt zugewiesen, wenn sie erstellt werden, wodurch der Code, der in Ihrer App- oder VM-Instanz ausgeführt wird, die erforderlichen Berechtigungen hat. In diesem Fall sind die Dienstkonten Identitäten, denen die Bearbeiterrolle für eine Ressource (Projekt) zugewiesen ist.
Wenn Sie Ihrer Anwendung den Zugriff auf einen Cloud Storage-Bucket gewähren möchten, gewähren Sie dem Dienstkonto, das Ihre Anwendung verwendet, die Berechtigungen zum Lesen des Cloud Storage-Buckets. In diesem Fall ist das Dienstkonto die Identität, der Sie Berechtigungen für eine andere Ressource (den Cloud Storage-Bucket) gewähren.
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.
Nutzer, denen die Rolle des Dienstkontonutzers für ein Dienstkonto zugewiesen wurde, können damit indirekt auf alle Ressourcen zugreifen, auf die das Dienstkonto Zugriff hat. Beispiel: Einem Dienstkonto wurde die Rolle des 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. In 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 IAM-Richtlinie.
- 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"
Diese Rolle ermöglicht den Identitätswechsel von Dienstkonten, um OAuth2-Zugriffstoken zu erstellen oder Blobs oder JWTs zu signieren.
Rolle "Dienstkontonutzer"
Diese Rolle wurde eingestellt. Wenn Sie Vorgänge mit einem Dienstkonto ausführen müssen, verwenden Sie die Rolle Dienstkontobenutzer. Sie sollten auch die Rolle Ersteller von Dienstkonto-Tokens zuweisen, um effektiv dieselben Berechtigungen wie für "Dienstkontonutzer" (Service Account Actor) zu gewähren.
Zugriffsbereiche
Zugriffsbereiche sind die Legacy-Methode zum Festlegen von Berechtigungen für Ihre VM. Als es noch keine IAM-Rollen gab, konnten Berechtigungen für Dienstkonten nur über Zugriffsbereiche erteilt werden. Obwohl Zugriffsbereiche jetzt nicht mehr die primäre Methode zum Zuweisen von Berechtigungen sind, müssen Sie sie auch weiterhin festlegen, wenn Sie eine Instanz konfigurieren, die als Dienstkonto ausgeführt werden soll. Informationen zu Zugriffsbereichen finden Sie in der Google 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.
Standardanmeldedaten für Anwendungen
Standardanmeldedaten für Anwendungen erleichtern die Nutzung von Dienstkonten bei der Verwendung innerhalb und außerhalb von Google Cloud sowie in mehreren Google Cloud-Projekten. Der häufigste Anwendungsfall ist das Testen von Code auf einem lokalen Computer, um diesen dann in ein Entwicklungsprojekt in Google Cloud und später in ein Produktionsprojekt in Google Cloud zu verschieben. Mit Standardanmeldedaten für Anwendungen wird sichergestellt, dass das Dienstkonto reibungslos funktioniert. Beim Testen auf Ihrem lokalen Computer wird ein lokal gespeicherter Dienstkontoschlüssel verwendet. Bei der Ausführung in Compute Engine wird jedoch das standardmäßige Compute Engine-Dienstkonto des Projekts verwendet. Weitere Informationen finden Sie unter Standardanmeldedaten für Anwendungen.
Weitere Informationen
Best Practices für die Verwendung von Dienstkonten finden Sie unter Informationen zu Dienstkonten.
Die folgenden Anleitungen enthalten weitere Informationen:
- Dienstkonten erstellen und verwalten
- Dienstkontoschlüssel erstellen und verwalten
- Allen Mitgliedstypen IAM-Rollen zuweisen, einschließlich Dienstkonten.