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. Ein Dienstkonto wird durch seine E-Mail-Adresse definiert, die für das Konto eindeutig ist.
Anwendungen verwenden Dienstkonten für autorisierte API-Aufrufe, die als Dienstkonto selbst oder als Google Workspace- oder Cloud Identity-Nutzer mithilfe domainweiter Delegation authentifiziert 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.
Es gibt noch andere Möglichkeiten, sich als Dienstkonto zu authentifizieren. In der Google Cloud-Befehlszeile können Sie beispielsweise das Flag --impersonate-service-account
verwenden, um sich beim Ausführen eines Befehls als Dienstkonto zu authentifizieren. Sie können auch einen Dienstkontoschlüssel erstellen und damit OAuth 2.0-Zugriffstokens abrufen.
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 öffentlichen/privaten RSA-Schlüsselpaaren zugeordnet, die für verschiedene Zwecke wie das 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.
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.
Arten von Dienstkonten
Nutzerverwaltete Dienstkonten
Sie können in Ihrem Projekt nutzerverwaltete Dienstkonten mit der IAM API, der Google 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:
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.
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.
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 | Standardmäßiges Compute Engine-Dienstkonto |
project-number-compute@developer.gserviceaccount.com
|
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. Diese Dienstkonten befinden sich nicht in Ihrem Projekt und Sie können nicht direkt darauf zugreifen.
Beispiele:
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:
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.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
.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
service-agent-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
service-agent-manager@system.gserviceaccount.com
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 Projektmy-application
, müssen Sie die Cloud SQL API in beidenmy-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.
Weitere Informationen zum Zuweisen von Rollen für Hauptkonten, einschließlich Dienstkonten, finden Sie unter Zugriff gewähren, ändern und entziehen.
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.
Die Berechtigungen dieser Rolle umfassen die Berechtigung iam.serviceAccounts.actAs
. Dadurch können Nutzer, denen die Rolle eines Dienstkontonutzers für ein Dienstkonto zugewiesen wurde, damit indirekt auf alle Ressourcen zugreifen, auf die das Dienstkonto Zugriff hat. Beispiel: Einem Dienstkonto wurde die Rolle eines 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. Bei 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 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.
- 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.
Rolle "Ersteller von Dienstkonto-Token"
Mit dieser Rolle können Hauptkonten die Identität von Dienstkonten übernehmen, um Folgendes zu tun:
- OAuth 2.0-Zugriffstokens erstellen, die Sie zur Authentifizierung bei Google APIs verwenden können
- OIDC-ID-Tokens (OpenID Connect) erstellen
- JSON Web Tokens (JWTs) und binäre Blobs signieren, damit sie für die Authentifizierung verwendet werden können
Weitere Informationen finden Sie unter Kurzfristige Anmeldedaten für Dienstkonten erstellen.
Die Berechtigungen der Rolle umfassen Folgendes:
iam.serviceAccounts.getAccessToken
: Ermöglicht das Erstellen von OAuth 2.0-Zugriffstokensiam.serviceAccounts.getOpenIdToken
: Ermöglicht das Erstellen von OIDC-ID-Tokens (OpenID Connect)iam.serviceAccounts.implicitDelegation
: Ermöglicht Dienstkonten, Tokens in einer Delegationskette zu erhalteniam.serviceAccounts.signBlob
: Ermöglicht das Signieren binärer Blobsiam.serviceAccounts.signJwt
: Ermöglicht das Signieren von JWTs
Rolle "Workload Identity-Nutzer"
Mit dieser Rolle 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-Zugriffstokensiam.serviceAccounts.getOpenIdToken
: Ermöglicht das Erstellen von OIDC-ID-Tokens (OpenID Connect)
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.
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 nutzerverwalteten Schlüsselpaars.
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. 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-Föderation verwenden, können Sie mit den Einschränkungen für Organisationsrichtlinien für die Workload Identity-Föderation angeben, welche Identitätsanbieter zulässig sind.
Nächste Schritte
- Erfahren Sie, wie Sie Dienstkonten erstellen und verwalten.
- Best Practices für die Arbeit mit Dienstkonten
- Mehr über das Erstellen und Verwalten von Dienstkontoschlüsseln
- 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