Stay organized with collections
Save and categorize content based on your preferences.
Workload identity enables you to assign distinct, fine-grained identities and
authorization for each application in your cluster. Workload identity is the
recommended way for applications running within GKE on AWS to access
AWS and Google Cloud services.
All GKE clusters have workload identity enabled.
Kubernetes service accounts
Workload identity implements identity federation, or delegating trust or roles
to an external provider. Each cluster has a built-in OpenID Connect (OIDC)
provider. When a Pod runs in the cluster, it runs using a
Kubernetes service account.
The Pod can be configured to obtain a token with short-lived credentials for
its Kubernetes service account using a
Bound Service Account Token Volume.
OpenID Connect providers
Each cluster can act as an
OpenID Connect (OIDC) provider. With
this provider, you can provide Kubernetes service account credentials to
services that support identity federation using OIDC.
This provider's issuer URI also serves as an OIDC discovery endpoint. Services
can use this discovery endpoint to obtain the JSON Web Key Set (JWKS), which
provides public key information that allows them to verify Kubernetes service
account credentials.
Google Cloud IAM identity pools and providers
Google Cloud IAM supports
identity federation using OIDC.
All GKE clusters are configured as identity providers in the
workload identity pool PROJECT_ID.svc.id.goog.
AWS IAM supports
identity federation using OIDC.
To access AWS using a workload's service account identities,
you need to
create an OIDC provider
on AWS IAM. By default, GKE on AWS are not configured with an
identity provider for AWS IAM.
Alternatives to workload identity
There are alternative methods to access services from GKE on AWS.
We don't recommended the following methods due to complications.
Export credentials and store them as Kubernetes Secrets. In this case,
you must rotate stored credentials manually in both AWS IAM and
in your cluster. Additionally, if an attacker steals credentials, they can
exploit them.
Attach credentials to the node pools's underlying instances. In this case,
all workloads running on the same node share the credentials,
which can result in a greater set of permissions than workloads might
need. To block access to an instance's permissions, GKE clusters
blocks access from a Pod to the instance metadata service.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# Workload identity overview\n\n*Workload identity* enables you to assign distinct, fine-grained identities and\nauthorization for each application in your cluster. Workload identity is the\nrecommended way for applications running within GKE on AWS to access\nAWS and Google Cloud services.\n\nAll GKE clusters have workload identity enabled.\n\nKubernetes service accounts\n---------------------------\n\nWorkload identity implements *identity federation* , or delegating trust or roles\nto an external provider. Each cluster has a built-in OpenID Connect (OIDC)\nprovider. When a Pod runs in the cluster, it runs using a\n[Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/).\nThe Pod can be configured to obtain a token with short-lived credentials for\nits Kubernetes service account using a\n[Bound Service Account Token Volume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume).\n\nOpenID Connect providers\n------------------------\n\nEach cluster can act as an\n[OpenID Connect (OIDC)](https://openid.net/connect/) provider. With\nthis provider, you can provide Kubernetes service account credentials to\nservices that support identity federation using OIDC.\n\nThis provider's issuer URI also serves as an OIDC discovery endpoint. Services\ncan use this discovery endpoint to obtain the JSON Web Key Set (JWKS), which\nprovides public key information that allows them to verify Kubernetes service\naccount credentials.\n\nGoogle Cloud IAM identity pools and providers\n---------------------------------------------\n\nGoogle Cloud IAM supports\n[identity federation using OIDC](https://cloud.google.com/iam/docs/workload-identity-federation).\nAll GKE clusters are configured as identity providers in the\nworkload identity pool \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e`.svc.id.goog`.\n\nTo get the name of your workload identity pool and providers, see\n[Use workload identity with Google Cloud](/kubernetes-engine/multi-cloud/docs/aws/how-to/use-workload-identity-google#determine_the_workload_identity_pool_for_your_cluster).\n\nAWS IAM identity providers\n--------------------------\n\nAWS IAM supports\n[identity federation using OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html).\nTo access AWS using a workload's service account identities,\nyou need to\n[create an OIDC provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html)\non AWS IAM. By default, GKE on AWS are not configured with an\nidentity provider for AWS IAM.\n\nAlternatives to workload identity\n---------------------------------\n\nThere are alternative methods to access services from GKE on AWS.\nWe don't recommended the following methods due to complications.\n\n1. Export credentials and store them as Kubernetes Secrets. In this case,\n you must rotate stored credentials manually in both AWS IAM and\n in your cluster. Additionally, if an attacker steals credentials, they can\n exploit them.\n\n2. Attach credentials to the node pools's underlying instances. In this case,\n all workloads running on the same node share the credentials,\n which can result in a greater set of permissions than workloads might\n need. To block access to an instance's permissions, GKE clusters\n blocks access from a Pod to the instance metadata service.\n\nWhat's next\n-----------\n\n- [Using workload identity with Google Cloud services](/kubernetes-engine/multi-cloud/docs/aws/how-to/use-workload-identity-google)\n- [Using workload identity with AWS](/kubernetes-engine/multi-cloud/docs/aws/how-to/use-workload-identity-aws)\n- Learn more about [Workload identity federation](/iam/docs/workload-identity-federation#pools)"]]