Dienstkonten

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 Compute-Arbeitslast verwendet wird, z. B. einer Compute Engine-VM-Instanz. Anwendungen verwenden Dienstkonten für autorisierte API-Aufrufe, die als Dienstkonto selbst oder als Google Workspace- oder Cloud Identity-Nutzer mithilfe domainweiter Delegation autorisiert werden.

Beispiel: Ein Dienstkonto kann an eine Compute Engine-VM angehängt werden, sodass sich auf dieser VM ausgeführte Anwendungen als das Dienstkonto authentifizieren können. Darüber hinaus können dem Dienstkonto IAM-Rollen zugewiesen werden, mit denen es auf Ressourcen zugreifen kann. Das Dienstkonto wird als Identität der Anwendung verwendet und die Rollen des Dienstkontos bestimmen, auf welche Ressourcen die Anwendung 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 öffentlich/privaten RSA-Schlüsselpaaren zugeordnet, die zur Authentifizierung bei Google und zum Signieren von Daten verwendet werden.
• Sie können zulassen, dass andere Nutzer oder Dienstkonten die Identität eines Dienstkontos übernehmen.

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

  Hinweis: Google Workspace-Assets, die erstellt werden, wenn die domainweite Delegation verwendet, werden in Ihrer Google Workspace-Domain erschaffen, da API-Aufrufe als imitierter Nutzer autorisiert werden, nicht als das Dienstkonto selbst.

Erstellen von Dienstkonten verhindern

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 Identitätsübernahme 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.

• Bei einigen Funktionen, darunter Workload Identity Federation, 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 und Google Groups

Sie können einer Google Group 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.

Schlüsseltypen für Dienstkonten

Jedes Dienstkonto ist einem öffentlichen/privaten RSA-Schlüsselpaar zugeordnet. Die Service Account Credentials API verwendet dieses interne Schlüsselpaar, um kurzlebige Anmeldedaten für Dienstkonten zu erstellen und Blobs und JSON-Web-Tokens (JWTs) zu signieren. Dieses Schlüsselpaar wird als von Google verwaltetes Schlüsselpaar bezeichnet.

Darüber hinaus können Sie mehrere öffentliche/private RSA-Schlüsselpaare erstellen, die als nutzerverwaltete Schlüsselpaare bezeichnet werden, und den privaten Schlüssel zum Authentifizieren bei Google APIs verwenden. Dieser private Schlüssel wird als Dienstkontoschlüssel bezeichnet.

Von Google verwaltete Schlüsselpaare

Von Google verwaltete Schlüsselpaare werden von der Service Account Credentials API und von Google Cloud-Diensten wie App Engine und Compute Engine verwendet, um kurzlebige Anmeldedaten für Dienstkonten zu generieren.

Von Google verwaltete Schlüsselpaare 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.

Der private Schlüssel in einem von Google verwalteten Schlüsselpaar wird immer treuhänderisch aufbewahrt. Sie können nicht direkt darauf zugreifen.

Der öffentliche Schlüssel in einem von Google verwalteten Schlüsselpaar ist öffentlich zugänglich, sodass jeder die mit dem privaten Schlüssel erstellten Signaturen überprüfen kann. Sie können auf den öffentlichen Schlüssel in verschiedenen Formaten zugreifen:

• X509Certificate: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
• JSON-Webschlüssel (JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
• Rohformat: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Wenn Sie den öffentlichen Schlüssel herunterladen und im Cache speichern, empfehlen wir, ihn für höchstens 24 Stunden im Cache zu speichern, damit Sie immer den aktuellen Schlüssel haben. Unabhängig davon, wann Sie den öffentlichen Schlüssel abrufen, ist er mindestens 24 Stunden nach dem Abruf gültig.

Von Nutzern verwaltete Schlüsselpaare

Sie können von Nutzern verwaltete Schlüsselpaare für ein Dienstkonto erstellen und sich dann mit dem privaten Schlüssel aus jedem Schlüsselpaar bei Google APIs authentifizieren. Dieser private Schlüssel wird als Dienstkontoschlüssel bezeichnet. Jedes Dienstkonto kann bis zu zehn Dienstkontoschlüssel haben. Google speichert nur den öffentlichen Teil eines von Nutzern verwalteten Schlüsselpaars.

Wichtig: Sie sind für die Sicherheit des privaten Schlüssels und für andere Verwaltungsvorgänge wie die Schlüsselrotation verantwortlich. Weitere Informationen finden Sie unter Best Practices für die Verwaltung von Dienstkontoschlüsseln.

Es gibt verschiedene Möglichkeiten, ein nutzerverwaltetes Schlüsselpaar für ein Dienstkonto zu erstellen:

• Verwenden Sie die IAM API, um ein nutzerverwaltetes Schlüsselpaar automatisch zu erstellen. Google generiert ein öffentliches/privates Schlüsselpaar; speichert nur den öffentlichen Schlüssel; und gibt den privaten Schlüssel zurück.
• Erstellen Sie selbst ein nutzerverwaltetes Schlüsselpaar und laden Sie dann nur den öffentlichen Schlüssel hoch. Google sieht den privaten Schlüssel nie.

Von Nutzern verwaltete Schlüssel sind äußerst leistungsstarke Anmeldedaten und können ein Sicherheitsrisiko darstellen, wenn sie nicht ordnungsgemäß verwaltet werden. Wenn Sie die Verwendung von nutzerverwalteten Schlüsseln einschränken möchten, können Sie die folgenden Einschränkungen für Organisationsrichtlinien für eine Organisation, ein Projekt oder einen Ordner erzwingen:

• constraints/iam.disableServiceAccountKeyCreation: verhindert, dass Hauptkonten nutzerverwaltete Dienstkontoschlüssel erstellen.
• constraints/iam.disableServiceAccountKeyUpload: verhindert, dass Hauptkonten einen öffentlichen Schlüssel für ein Dienstkonto hochladen.

Wenn Sie diese Einschränkungen erzwingen, weil Sie die Workload Identity Federation verwenden, können Sie mit den Einschränkungen für Organisationsrichtlinien für die Workload Identity Federation angeben, welche Identitätsanbieter zulässig sind.

Ablaufzeit für von Nutzern verwaltete Schlüssel angeben

Vorschau –setting an expiry time for new service account keys

Diese Funktion unterliegt den Nutzungsbedingungen des Pre-GA-Angebots der Google Cloud-Nutzungsbedingungen. Pre-GA-Funktionen werden möglicherweise nur eingeschränkt unterstützt. Änderungen an Pre-GA-Funktionen sind möglicherweise nicht mit anderen Pre-GA-Versionen kompatibel. Weitere Informationen finden Sie unter Beschreibungen der Startphase.

Informationen zum Zugriff auf diesen Release finden Sie auf der Seite Zugriffsanforderung.

Wenn Sie einen von Nutzern verwalteten Dienstkontoschlüssel erstellen, läuft der Schlüssel standardmäßig nie ab. Sie können diese Standardeinstellung ändern, indem Sie eine Ablaufzeit für alle neu erstellten Schlüssel in Ihrem Projekt, Ordner oder Ihrer Organisation festlegen.

Verwenden Sie Ablaufzeiten, wenn Sie vorübergehend auf ein System zugreifen müssen, insbesondere wenn das System einen Dienstkontoschlüssel erfordert. Verwenden Sie beispielsweise Ablaufzeiten in diesen Szenarien:

• Ein Entwickler muss ein Codelab ausführen, für das Dienstkontoschlüssel erforderlich sind.
• Ein Entwickler muss ein Befehlszeilentool ausführen, für das ein Dienstkontoschlüssel erforderlich ist.
• Temporäre Mitarbeiter, wie Praktikanten oder Auftragnehmer, erstellen einen Proof of Concept für eine neue Anwendung.

Vermeiden Sie in diesen Szenarien Ablaufzeiten:

• Produktionsarbeitslasten: In der Produktion kann ein abgelaufener Dienstkontoschlüssel einen versehentlichen Ausfall verursachen. Verwenden Sie stattdessen Schlüssel, die nicht ablaufen, und verwalten Sie ihren Lebenszyklus mit Schlüsselrotation.
• Nicht-Produktionsarbeitslasten, die dauerhaften Zugriff benötigen, z. B. eine CI-Pipeline (Continuous Integration).

Wenn Sie eine Ablaufzeit festlegen möchten, verwenden Sie Ressourceneinstellungen, um die Einstellung settings/iam-serviceAccountKeyExpiry zu aktualisieren. Nachdem Sie diese Einstellung für Ihr Projekt, Ihren Ordner oder Ihre Organisation aktualisiert haben, gilt die Ablaufzeit für alle neu erstellten Dienstkontoschlüssel innerhalb dieser übergeordneten Ressource. Vorhandene Schlüssel sind nicht betroffen.

Wichtig: Damit Ausfälle vermieden werden, sollten Sie keine Ablaufzeit festlegen, es sei denn, die constraints/iam.disableServiceAccountKeyCreation Einschränkung der Organisationsrichtlinie ist bereits für einen längeren Zeitraum vorhanden. Nachdem Sie die Ressourceneinstellung aktualisiert haben, müssen Sie diese Einschränkung auch aus der Organisationsrichtlinie entfernen.

Wenn diese Einschränkung nicht vorhanden war, müssen Sie eng mit den Nutzern des Projekts, Ordners oder der Organisation zusammenarbeiten, um zu bestätigen, dass keine ihrer vorhandenen Ressourcen permanente Dienstkontoschlüssel erfordert. Wenn eine Ressource permanente Dienstkontoschlüssel erfordert und Sie eine Ablaufzeit festlegen, kommt es wahrscheinlich zu einem Ausfall.

Weitere Informationen zu dieser Einstellung finden Sie im Index für Ressourceneinstellungen. Informationen zum Aktualisieren der Einstellung finden Sie unter Wert für eine lokale Einstellung ändern.

Verwenden Sie als Best Practice kurze Ablaufzeiten wie 8hours, 24hours oder 7days. Kurze Ablaufzeiten sorgen dafür, dass Ihr Team einen gut erprobten Prozess zum Aktualisieren von Schlüsseln hat. Beginnen Sie mit der kürzesten Ablaufzeit, die Ihren Anforderungen entspricht, und erhöhen Sie sie nur, wenn es unbedingt notwendig ist.

Arten von Dienstkonten

Nutzerverwaltete Dienstkonten

Sie können in Ihrem Projekt nutzerverwaltete Dienstkonten mit der IAM API, der Cloud Console oder der Google Cloud CLI 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:

[e-mail]

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.

Wenn Ihre Anwendung in einer Google Cloud-Umgebung mit einem Standarddienstkonto ausgeführt wird, kann sie mit den Anmeldedaten für das Standarddienstkonto Google Cloud APIs aufrufen. Alternativ können Sie Ihr eigenes nutzerverwaltetes Dienstkonto erstellen und es zur Authentifizierung verwenden. Weitere Informationen finden Sie unter Anmeldedaten automatisch finden.

Wichtig: 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, indem Sie entweder Ihrer Organisationsrichtlinie eine Einschränkung hinzufügen oder die Bearbeiterrolle manuell aufheben. Wenn Sie die Rollenzuweisung deaktivieren oder aufheben, müssen Sie festlegen, welche Rollen den Standarddienstkonten zugeteilt werden sollen.

Wenn Sie eine Rollenbindung ersetzen, die seit mehr als 90 Tagen besteht, können Sie mithilfe der Rollenempfehlungen feststellen, welche Rollen stattdessen zugewiesen werden sollen. Sie können auch den Policy Simulator verwenden, um sicherzustellen, dass sich eine Änderung der Rolle nicht auf den Zugriff des Dienstkontos auswirkt.

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	[e-mail]
Compute Engine und alle Google Cloud-Dienste, die Compute Engine nutzen	Standardmäßiges Compute Engine-Dienstkonto	[e-mail]

Hinweis: Sowohl das Erstellungsdatum als auch das E-Mail-Adressformat von Standarddienstkonten können geändert werden.

Von Google verwaltete Dienstkonten

Einige Google Cloud-Dienste benötigen Zugriff auf Ihre Ressourcen, damit sie Aufgaben für Sie ausführen können. Wenn Sie beispielsweise einen Container mit Cloud Run ausführen, benötigt der Dienst Zugriff auf alle Pub/Sub-Themen, die den Container auslösen können.

Damit dies möglich ist, erstellt und verwaltet Google Dienstkonten für viele Google Cloud-Dienste. Diese Dienstkonten werden als von Google verwaltete Dienstkonten bezeichnet. Unter Umständen sehen Sie von Google verwaltete Dienstkonten in der Zulassungsrichtlinie Ihres Projekts, in Audit-Logs oder auf der IAM-Seite in der Cloud Console.

Von Google verwaltete Dienstkonten werden in der Cloud Console auf der Seite Dienstkonten nicht aufgeführt.

Hinweis: Das Erstellungsdatum und das E-Mail-Adressformat für diese Dienstkonten können sich ändern.

Beispiel:

• Google APIs-Dienst-Agent: Die Zulassungsrichtlinie Ihres Projekts verweist wahrscheinlich auf ein Dienstkonto mit dem Namen des Google APIs-Dienst-Agents mit einer E-Mail-Adresse im folgenden Format: [e-mail].

  Dieses Dienstkonto führt in Ihrem Namen interne Google-Prozesse aus. Es erhält automatisch die Rolle "Bearbeiter" (roles/editor) für das Projekt.

  Warnung: Ignorieren Sie die Rollen, die dem Google APIs-Dienst-Agent gewährt werden, nur, wenn dies durch eine Rollenempfehlung vorgeschlagen wird. Wenn Sie diese Rollen auf eine Weise widerrufen, die nicht durch eine Rollenempfehlung vorgeschlagen wird, funktionieren einige Google Cloud-Dienste nicht mehr.

• Andere Dienst-Agents: Die Zulassungsrichtlinie Ihres Projekts bezieht sich möglicherweise auf andere von Google verwaltete Dienstkonten, die im Namen einzelner Dienste agieren. Diese Dienstkonten werden als Dienst-Agents bezeichnet. Diesen Dienst-Agents können automatisch Rollen zugewiesen werden. Die Namen dieser Rollen enden normalerweise auf serviceAgent.

  Warnung: Wenn keine Rollenempfehlung dies vermuten, sollten Sie die Rollen, die Dienst-Agents zugewiesen sind, nicht widerrufen. Wenn Sie diese Rollen auf eine Weise widerrufen, die nicht durch eine Rollenempfehlung empfohlen wird, funktionieren einige Google Cloud-Dienste nicht mehr.

  Eine vollständige Liste der Dienst-Agents und der Rollen, die jedem einzelnen automatisch zugewiesen werden, finden Sie unter Dienst-Agents.

• Rollenmanager für von Google verwaltete Dienstkonten: Ihre Audit-Logs für IAM beziehen sich möglicherweise auf das Dienstkonto [e-mail].

  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 [e-mail] die Zulassungsrichtlinie für das Projekt festgelegt hat.

Dienstkonto-Standorte

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.

Dienstkontoberechtigungen

Dienstkonten sind Identitäten und Ressourcen.

Da es sich bei Dienstkonten um Identitäten 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.

Hinweis: Sofern Sie nicht die Einschränkung von Organisationsrichtlinien aktiviert haben, um automatische Rollenzuweisungen für Standarddienstkonten zu deaktivieren, wird den standardmäßigen Compute Engine- und App Engine-Dienstkonten die Rolle „Bearbeiter” (roles/editor) für das Projekt zugewiesen, wenn sie erstellt werden. Weitere Informationen finden Sie unter Standard-Dienstkonten auf dieser Seite.

Dienstkonten sind jedoch auch Ressourcen, die Zulassungsrichtlinien akzeptieren. 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 „Dienstkontonutzer” (roles/iam.serviceAccountUser) für das Dienstkonto zuweisen.

Weitere Informationen zum Zuweisen von Rollen für Hauptkonten, einschließlich Dienstkonten, finden Sie unter Zugriff gewähren, ändern und entziehen.

Weitere Informationen zum Zuweisen von Nutzerrollen für Dienstkonten finden Sie unter Identitätswechsel für Dienstkonten verwalten.

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.

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

Zugriffsbereiche

Zugriffsbereiche sind eine Legacy-Methode zum Festlegen von Berechtigungen für eine Compute Engine-VM-Instanz. Sie definieren die standardmäßigen OAuth-Bereiche, die in Anfragen von der gcloud CLI und Clientbibliotheken verwendet werden.

Google Cloud verwendet jetzt IAM, keine Zugriffsbereiche, um Berechtigungen für Compute Engine-Instanzen anzugeben. Sie müssen dennoch einen Zugriffsbereich festlegen, wenn Sie eine Instanz konfigurieren, um die Identität eines Dienstkontos zu übernehmen.

Weitere Informationen finden Sie in der 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.

Workload Identity-Föderation

Sie können Identitäten von Arbeitslasten, die außerhalb von Google Cloud ausgeführt werden, z. B. auf Amazon Web Services (AWS) oder Microsoft Azure, die Möglichkeit geben, die Identität eines Dienstkontos zu übernehmen. So lässt sich mithilfe kurzlebiger Anmeldedaten direkt auf Ressourcen zugreifen, anstatt einen Dienstkontoschlüssel zu verwenden.

Weitere Informationen finden Sie unter Workload Identity-Föderation.

Standardanmeldedaten für Anwendungen

Standardanmeldedaten für Anwendungen ist ein Tool, mit dem Google Cloud-Clientbibliotheken die Anmeldedaten von Dienstkonten automatisch erkennen. Sie können einen Dienstkontoschlüssel in einer Umgebungsvariablen angeben. Die Standardanmeldedaten für Anwendungen verwenden diesen Dienstkontoschlüssel automatisch. Wenn Sie keinen Schlüssel angeben, verwenden die Standardanmeldedaten für Anwendungen das Dienstkonto, das an die Ressource angehängt ist, die Ihren Code ausführt, oder das Standarddienstkonto für den Dienst, auf dem Ihr Code ausgeführt wird.

Weitere Informationen finden Sie unter Anmeldedaten automatisch finden.

Nächste Schritte

• Erfahren Sie, wie Sie Dienstkonten erstellen und verwalten.
• Mehr über das Erstellen und Verwalten von Dienstkontoschlüsseln
• Best Practices für die Verwendung und Verwaltung von Dienstkonten
• Best Practices zum Schützen von Dienstkonten
• Best Practices für die Verwaltung von Dienstkontoschlüsseln

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