This page describes the identity types that you can use to configureyour workloads' access to Google Cloud resources.

Google Cloud provides the following types of identities for workloads:

• Workload Identity Federation andWorkload Identity Federation for GKE let your workloads accessmost Google Cloud services by using federated identities that areauthenticated through an external identity provider (IdP). AfterGoogle Cloud authenticates the identity as a principal, the principalcan access resources by using IAM roles that you grant.

• Google Cloud service accounts can act asidentities for workloads in production environments. Instead of granting accessto a workload directly, you grant access to a service account, then have theworkload use the service account as its identity.

• Managed workload identities(Preview)let you bind strongly attested identities to your Compute Engine andGKE workloads.

• Agent identities(Preview)are Google-managed identities for agentic workloads. Agent identities areattested and tied to the lifecycle of the agents.This provides a more secure way to manage agent access to Google Cloudresources than using service accounts.

The types of identities that you can use for workloads and the way that youconfigure 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 followingmethods 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 Engineand GKE only)
• Service account keys

Attached service accounts

For some Google Cloud resources, you can specify a user-managed service account that theresource uses as its default identity. This process is known asattaching the serviceaccount to the resource, orassociating the service account with the resource.When code running on the resource accesses Google Cloud services and resources, it uses theservice account attached to the resource as its identity. For example, if youattach aservice account to a Compute Engine instance, and the applications on the instance use aclient library to call Google Cloud APIs,those applications automatically use the attached service account for authentication andauthorization.

In most cases, you must attach a service account to a resource when you createthat resource. After the resource is created, you cannot change which serviceaccount is attached to the resource. Compute Engine instances are anexception to this rule; you can change which service account is attached to aninstance as needed.

To learn more, seeAttach a service account to a resource.

Workload Identity Federation for GKE

For workloads that run on GKE, Workload Identity Federation for GKE lets yougrant IAM roles to distinct, fine-grained sets of principals, foreach application in your cluster. Workload Identity Federation for GKE lets Kubernetesservice accounts in your GKE cluster access Google Cloudresources 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 theKubernetes service account identity directly on the Google Cloud service'sresources. Most Google Cloud APIs support direct resource access. However,when using identity federation, certain API methods might have limitations. Fora list of these limitations, seeSupported products and limitations.

As an alternative, workloads can also use service account impersonation, wherethe configured Kubernetes ServiceAccount is bound to an IAMservice account, which serves as the identity when accessing Google CloudAPIs.

To learn more about GKE Workload Identity Federation for GKE, seeWorkload Identity Federation for GKE.

Managed workload identities

Preview

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

Managed workload identities let you bind strongly attested identities to yourCompute Engine and GKE workloads. You can use managedworkload identities to authenticate your workloads to other workloads usingmTLS.

To learn more about managed workload identities, seeManaged workload identities overview.

Agent identities

Preview

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

An agent identity is a Google-managed identity for agentic workloads. An agentidentity is attested and tied to the lifecycle of the agent, which providesa more secure way to manage agent access to Google Cloud resources thanusing service accounts.

Existing access management controls through IAM support agentidentity to enable strong governance.

To learn more about agent identities and how to use them, seeUse agent identity with Vertex AI Agent Engine.

Configure external workloads

If you're running workloads outside of Google Cloud, you can use thefollowing methods to configure identities for your workloads:

• Workload Identity Federation
• Service account keys

Workload Identity Federation

You can use Workload Identity Federation with workloads onGoogle Cloud or external workloads that run on platforms such as AWS,Azure, GitHub, and GitLab.

Workload Identity Federation lets you use credentials from external identityproviders likeAWS, Azure, andActive Directoryto generate short-lived credentials, which workloads can use to temporarilyimpersonate service accounts. Workloads can then access Google Cloudresources, using the service account as their identity.

Workload Identity Federation is the preferred way to configure identities forexternal workloads.

To learn more about Workload Identity Federation, seeWorkload Identity Federation.

Service account keys

A service account key lets a workload authenticate as a service account, thenuse the service account's identity for authorization.

Note: Service account keys are a security risk if not managed correctly. You should choose a more secure alternative to service account keyswhenever possible. If you must authenticate with a service account key, you are responsible for thesecurity of the private key and for other operations described by Best practices for managing service account keys.If you are prevented from creating a service account key, service account key creation mightbe disabled for your organization. For more information, see Managing secure-by-default organization resources.

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.

Local development

If you're developing in a local environment, you can configure workloads to useeither your user credentials or a service account for authentication andauthorization. For more information, seeLocal development environment in the authentication documentation.

What's next

• Learn how toset up authentication by using service accounts.
• Learn how toset up authentication for a local development environment.
• Learn how togrant service accounts access to resources.