Workload identity overview

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 Azure to access Azure 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.

To get the name of your workload identity pool and providers, see Use workload identity with Google Cloud.

Alternatives to workload identity

There are alternative methods to access services from GKE on Azure. We don't recommended the following methods due to complications.

  1. Export credentials and store them as Kubernetes Secrets. In this case, you must rotate stored credentials manually in both Azure IAM and in your cluster. Additionally, if an attacker steals credentials, they can exploit them.

  2. 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.

What's next