This page describes the identity types that you can use to configure your workloads' access to Google Cloud resources. Google Cloud provides the following types of identities for workloads: - [**Workload Identity Federation**](https://docs.cloud.google.com/iam/docs/workload-identity-federation.md.txt) and [**Workload Identity Federation for GKE**](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/workload-identity.md.txt) let your workloads access most Google Cloud services by using federated identities that are authenticated through an external identity provider (IdP). After Google Cloud authenticates the identity as a principal, the principal can access resources by using IAM roles that you grant. - [**Google Cloud service accounts**](https://docs.cloud.google.com/iam/docs/service-account-overview.md.txt) can act as identities for workloads in production environments. Instead of granting access to a workload directly, you grant access to a service account, then have the workload use the service account as its identity. - [**Managed workload identities**](https://docs.cloud.google.com/iam/docs/managed-workload-identity.md.txt) let you bind strongly attested identities to your Compute Engine and GKE workloads. - [**Agent identities**](https://docs.cloud.google.com/iam/docs/workload-identities.md.txt#agent-identity) are Google-managed identities for agentic workloads. Agent identities are attested and tied to the lifecycle of the agents. This provides a more secure way to manage agent access to Google Cloud resources than using service accounts. The types of identities that you can use for workloads and the way that you configure them depends on where your workloads are running. ## Configure workloads on Google Cloud If you're running workloads on Google Cloud, you can use the following methods to configure identities for your workloads: - Attached service accounts - Workload Identity Federation for GKE (for workloads running on Google Kubernetes Engine only) - Managed workload identities (for workloads that run on Compute Engine and GKE only) - Service account keys ### Attached service accounts For some Google Cloud resources, you can specify a user-managed service account that the resource uses as its default identity. This process is known as *attaching* the service account to the resource, or *associating* the service account with the resource. When code running on the resource accesses Google Cloud services and resources, it uses the service account attached to the resource as its identity. For example, if you [attach a service account to a Compute Engine instance](https://docs.cloud.google.com/compute/docs/access/service-accounts#associating_a_service_account_to_an_instance), and the applications on the instance use a [client library](https://docs.cloud.google.com/apis/docs/client-libraries-explained.md.txt) to call Google Cloud APIs, those applications automatically use the attached service account for authentication and authorization. In most cases, you must attach a service account to a resource when you create that resource. After the resource is created, you cannot change which service account is attached to the resource. Compute Engine instances are an exception to this rule; you can change which service account is attached to an instance as needed. To learn more, see [Attach a service account to a resource](https://docs.cloud.google.com/iam/docs/attach-service-accounts.md.txt). ### Workload Identity Federation for GKE For workloads that run on GKE, Workload Identity Federation for GKE lets you grant IAM roles to distinct, fine-grained sets of principals, for each application in your cluster. Workload Identity Federation for GKE lets Kubernetes service accounts in your GKE cluster access Google Cloud resources directly, by using Workload Identity Federation, or indirectly, by using IAM service account impersonation. By using direct resource access, you can grant IAM roles to the Kubernetes service account identity directly on the Google Cloud service's resources. Most Google Cloud APIs support direct resource access. However, when using identity federation, certain API methods might have limitations. For a list of these limitations, see [Supported products and limitations](https://docs.cloud.google.com/iam/docs/federated-identity-supported-services.md.txt). As an alternative, workloads can also use service account impersonation, where the configured Kubernetes ServiceAccount is bound to an IAM service account, which serves as the identity when accessing Google Cloud APIs. To learn more about GKE Workload Identity Federation for GKE, see [Workload Identity Federation for GKE](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/workload-identity.md.txt). ### Managed workload identities Managed workload identities let you bind strongly attested identities to your Compute Engine and GKE workloads. You can use managed workload identities to authenticate your workloads to other workloads using [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication). To learn more about managed workload identities, see [Managed workload identities overview](https://docs.cloud.google.com/iam/docs/managed-workload-identity.md.txt). ### Agent identities An agent identity is a Google-managed identity for agentic workloads. An agent identity is attested and tied to the lifecycle of the agent, which provides a more secure way to manage agent access to Google Cloud resources than using service accounts. Existing access management controls through IAM support agent identity to enable strong governance. To learn more about agent identities and how to use them, see [Use agent identity with Vertex AI Agent Engine](https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity.md.txt). ## Configure external workloads If you're running workloads outside of Google Cloud, you can use the following methods to configure identities for your workloads: - Workload Identity Federation - Service account keys ### Workload Identity Federation You can use Workload Identity Federation with workloads on Google Cloud or external workloads that run on platforms such as AWS, Azure, GitHub, and GitLab. Workload Identity Federation lets you use credentials from external identity providers like [AWS, Azure](https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-other-clouds.md.txt), and [Active Directory](https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-active-directory.md.txt) 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. Workload Identity Federation is the preferred way to configure identities for external workloads. To learn more about Workload Identity Federation, see [Workload Identity Federation](https://docs.cloud.google.com/iam/docs/workload-identity-federation.md.txt). ### Service account keys A service account key lets a workload authenticate as a service account, then use the service account's identity for authorization. > [!NOTE] > **Note:** Service account keys are a security risk if not managed correctly. You should [choose a more secure alternative to service account keys](https://docs.cloud.google.com/docs/authentication.md.txt#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](https://docs.cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys.md.txt). 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](https://docs.cloud.google.com/resource-manager/docs/secure-by-default-organizations). > > > If you acquired the service account key from an external source, you must validate it before use. > For more information, see [Security requirements for externally sourced credentials](https://docs.cloud.google.com/docs/authentication/external/externally-sourced-credentials).
## Local development If you're developing in a local environment, you can configure workloads to use either your user credentials or a service account for authentication and authorization. For more information, see [Local development environment](https://docs.cloud.google.com/docs/authentication/set-up-adc-local-dev-environment.md.txt) in the authentication documentation. ## What's next - Learn how to [set up authentication by using service accounts](https://docs.cloud.google.com/docs/authentication.md.txt#service-accounts). - Learn how to [set up authentication for a local development environment](https://docs.cloud.google.com/docs/authentication/set-up-adc-local-dev-environment.md.txt). - Learn how to [grant service accounts access to resources](https://docs.cloud.google.com/iam/docs/granting-changing-revoking-access.md.txt).