Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Um Google Cloudverwenden zu können, benötigen Nutzer und Arbeitslasten eine Identität, dieGoogle Cloud erkennen kann.
Auf dieser Seite werden die Methoden beschrieben, mit denen Sie Identitäten für Nutzer und Arbeitslasten konfigurieren können.
Nutzer-IDs
Es gibt mehrere Möglichkeiten, Nutzeridentitäten zu konfigurieren, damit Google Cloudsie erkennen kann:
Cloud Identity- oder Google Workspace-Konten erstellen: Nutzer mit Cloud Identity- oder Google Workspace-Konten können sich bei Google Cloud authentifizieren und zur Verwendung von Google Cloud -Ressourcen autorisiert sein.
Cloud Identity- und Google Workspace-Konten sind Nutzerkonten, die von Ihrer Organisation verwaltet werden.
Richten Sie eine der folgenden Strategien für föderierte Identitäten ein:
Föderation mit Cloud Identity oder Google Workspace: Synchronisieren Sie externe Identitäten mit entsprechenden Cloud Identity- oder Google Workspace-Konten, damit sich Nutzer mit ihren externen Anmeldedaten bei Google-Diensten anmelden können. Bei dieser Methode benötigen Nutzer zwei Konten: ein externes Konto und ein Cloud Identity- oder Google Workspace-Konto. Sie können diese Konten mithilfe eines Tools wie Google Cloud Directory Sync (GCDS) synchronisieren.
Workforce Identity-Föderation: Verwenden Sie Ihren externen Identitätsanbieter (Identity Provider, IdP), um Ihre Nutzer bei Google Cloud anzumelden und ihnen Zugriff aufGoogle Cloud -Ressourcen und ‑Produkte zu gewähren.
Bei der Workforce Identity-Föderation benötigen Nutzer nur ein Konto: ihr externes Konto. Diese Art von Nutzeridentität wird manchmal auch als föderierte Identität bezeichnet.
Weitere Informationen zu diesen Methoden zum Einrichten von Nutzeridentitäten finden Sie unter Übersicht über Nutzeridentitäten.
Workload Identitys
Google Cloud bietet die folgenden Identitätsdienste für Arbeitslasten:
Mit der Workload Identity-Föderation können Ihre Arbeitslasten über eine Identität, die von einem IdP bereitgestellt wird, auf die meisten Google Cloud Dienste zugreifen. Arbeitslasten, die die Workload Identity-Föderation verwenden, können auf Google Cloud, der Google Kubernetes Engine (GKE) oder anderen Plattformen wie AWS, Azure und GitHub ausgeführt werden.
Google Cloud Dienstkonten können als Identitäten für Arbeitslasten fungieren. Anstatt direkt auf eine Arbeitslast Zugriff zu erteilen, gewähren Sie einen Zugriff auf ein Dienstkonto und lassen die Arbeitslast dann das Dienstkonto als Identität verwenden.
Mit verwalteten Arbeitslastidentitäten(Vorabversion) können Sie stark attestierte Identitäten an Ihre Compute Engine-Arbeitslasten binden. Sie können verwaltete Arbeitslastidentitäten verwenden, um Ihre Arbeitslasten über gegenseitige TLS-Authentifizierung (mTLS) bei anderen Arbeitslasten zu authentifizieren. Sie können jedoch nicht für die Authentifizierung bei Google Cloud APIs verwendet werden.
Welche Methoden Sie verwenden können, hängt davon ab, wo Ihre Arbeitslasten ausgeführt werden.
Wenn Sie Arbeitslasten auf Google Cloudausführen, können Sie Workload Identitys mit den folgenden Methoden konfigurieren:
Workload Identity Federation for GKE: Gewähren Sie IAM-Zugriff auf GKE-Cluster und Kubernetes-Dienstkonten. So können die Arbeitslasten der Cluster direkt auf die meisten Google Cloud Dienste zugreifen, ohne die Identität eines IAM-Dienstkontos zu übernehmen.
Angehängte Dienstkonten: Hängen Sie ein Dienstkonto an eine Ressource an, damit das Dienstkonto als Standardidentität der Ressource fungiert. Alle auf der Ressource ausgeführten Arbeitslasten verwenden beim Zugriff aufGoogle Cloud -Dienste die Identität des Dienstkontos.
Kurzlebige Anmeldedaten für Dienstkonten: Generieren und verwenden Sie kurzlebige Anmeldedaten für Dienstkonten, wenn Ihre Ressourcen aufGoogle Cloud -Dienste zugreifen müssen. Die gängigsten Arten von Anmeldedaten sind OAuth 2.0-Zugriffstokens und OIDC-ID-Tokens (OpenID Connect).
Wenn Sie Arbeitslasten außerhalb von Google Cloudausführen, können Sie Workload Identitys mit den folgenden Methoden konfigurieren:
Workload Identity-Föderation: Verwenden Sie Anmeldedaten von externen Identitätsanbietern, um kurzlebige Anmeldedaten zu generieren, mit denen Arbeitslasten vorübergehend die Identität von Dienstkonten übernehmen können. Arbeitslasten können dann über das Dienstkonto als Identität aufGoogle Cloud -Ressourcen zugreifen.
Dienstkontoschlüssel: Verwenden Sie den privaten Teil des öffentlichen/privaten RSA-Schlüsselpaars eines Dienstkontos, um sich als Dienstkonto zu authentifizieren.
Weitere Informationen zu diesen Methoden zum Einrichten von Workload Identitys finden Sie unter Workload Identity-Übersicht.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-21 (UTC)."],[[["\u003cp\u003eGoogle Cloud requires users and workloads to have a recognizable identity for access.\u003c/p\u003e\n"],["\u003cp\u003eUser identities can be established through Cloud Identity/Google Workspace accounts or by setting up federated identity strategies.\u003c/p\u003e\n"],["\u003cp\u003eWorkload identities on Google Cloud can use Workload Identity Federation, Google Cloud service accounts, or managed workload identities.\u003c/p\u003e\n"],["\u003cp\u003eWorkload identities for workloads outside of Google Cloud can leverage Workload Identity Federation or service account keys, with the latter carrying security risks.\u003c/p\u003e\n"],["\u003cp\u003eThe method to choose to configure a workload identity depends on where the workloads are running, in or out of Google cloud.\u003c/p\u003e\n"]]],[],null,["# Identity management for Google Cloud\n\nTo use Google Cloud, users and workloads need an identity that\nGoogle Cloud can recognize.\n\nThis page outlines the methods that you can use to configure identities for\nusers and workloads.\n\nUser identities\n---------------\n\nThere are several ways to configure user identities so that Google Cloud\ncan recognize them:\n\n- **Create Cloud Identity or Google Workspace accounts**: Users with Cloud Identity or Google Workspace accounts can authenticate to Google Cloud and be authorized to use Google Cloud resources. Cloud Identity and Google Workspace accounts are user accounts that are managed by your organization.\n\n| **Note:** Google Workspace accounts may have one or more *[alternate email addresses (email alias)](https://support.google.com/a/answer/33327)* . If you grant a role to a principal's *email alias* , the role is granted to the *primary email* instead. It's not possible to grant a role to only the *email alias*.\n| **Warning:** Granting a role to a principal's *email alias* reveals the *primary email*.\n\n- **Set up one of the following federated identity strategies**:\n\n - **Federation using Cloud Identity or Google Workspace** : Sync external identities with corresponding Cloud Identity or Google Workspace accounts so that users can sign in to Google services with their external credentials. With this method, users need two accounts: an external account, and a Cloud Identity or Google Workspace account. You can keep these accounts synchronized using a tool like [Google Cloud Directory Sync\n (GCDS)](https://tools.google.com/dlpage/dirsync/).\n - **Workforce Identity Federation** : Use your external identity provider (IdP) to sign in your users to Google Cloud and let them access Google Cloud resources and products. With Workforce Identity Federation, users need only one account: their external account. This type of user identity is sometimes referred to as a *federated identity*.\n\nTo learn more about these methods for setting up user identities, see\n[User identities overview](/iam/docs/user-identities).\n\nWorkload identities\n-------------------\n\nGoogle Cloud provides the following types of identity services for workloads:\n\n- [**Workload Identity Federation**](/iam/docs/workload-identity-federation)\n lets your workloads access most Google Cloud services by using an\n identity that is provided by an IdP. Workloads that use\n Workload Identity Federation can run on Google Cloud,\n Google Kubernetes Engine (GKE), or other platforms, such as AWS, Azure, and\n GitHub.\n\n- [**Google Cloud service accounts**](/iam/docs/service-account-overview) can act as\n identities for workloads. Instead of granting access to a workload directly,\n you grant access to a service account, then let the workload use the service\n account as its identity.\n\n- [**Managed workload identities**](/iam/docs/managed-workload-identity) [**(Preview)**](/products#product-launch-stages)\n let you bind strongly attested identities to your Compute Engine\n workloads. You can use managed workload identities to authenticate your\n workloads to other workloads using [mutual TLS (mTLS)](https://en.wikipedia.org/wiki/Mutual_authentication),\n but they cannot be used for authenticating to Google Cloud APIs.\n\nThe methods that you can use depend on where your workloads are running.\n\nIf you're running workloads on Google Cloud, you can use the following\nmethods to configure workload identities:\n\n- **Workload Identity Federation for GKE**: Grant IAM access to\n GKE clusters and Kubernetes service accounts. Doing so lets the\n clusters' workloads access most Google Cloud services directly, without\n using IAM service account impersonation.\n\n- **Attached service accounts**: Attach a service account to a resource so that\n the service account acts as the resource's default identity. Any workloads\n running on the resource use the service account's identity when accessing\n Google Cloud services.\n\n- **Short-lived service account credentials**: Generate and use short-lived\n service account credentials whenever your resources need to access to\n Google Cloud services. The most common types of credentials are\n OAuth 2.0 access tokens and OpenID Connect (OIDC) ID tokens.\n\nIf you're running workloads outside of Google Cloud, you can use the\nfollowing methods to configure workload identities:\n\n- **Workload Identity Federation**: Use credentials from external identity providers to generate short-lived credentials, which workloads can use to temporarily impersonate service accounts. Workloads can then access Google Cloud resources, using the service account as their identity.\n- **Service account keys**: Use the private portion of a service account's\n public/private RSA key pair to authenticate as the service account.\n\n | **Important:** Service account keys are a security risk if not managed correctly. You should [choose a more secure alternative to service account keys](/docs/authentication#auth-decision-tree) whenever possible. If you must authenticate with a service account key, you are responsible for the security of the private key and for other operations described by [Best practices for managing service account keys](/iam/docs/best-practices-for-managing-service-account-keys). If you are prevented from creating a service account key, service account key creation might be disabled for your organization. For more information, see [Managing secure-by-default organization resources](/resource-manager/docs/secure-by-default-organizations).\n |\n |\n | If you acquired the service account key from an external source, you must validate it before use.\n | For more information, see [Security requirements for externally sourced credentials](/docs/authentication/external/externally-sourced-credentials).\n\nTo learn more about these methods for setting up workload identities, see\n[Workload identities overview](/iam/docs/workload-identities)."]]