Understanding Workload Identity in Google Kubernetes Engine (GKE)

When deploying workloads to Google Kubernetes Engine (GKE), applications frequently need access to Google Cloud services such as Cloud Storage, Cloud SQL, or Secret Manager.

Traditionally, developers often solved this by generating a Google Cloud Service Account (GSA) private key in JSON format and storing it as a Kubernetes Secret. However, managing static keys introduces significant maintenance and operational risks.

Google Cloud provides Workload Identity, which allows Kubernetes workloads to authenticate to Google Cloud APIs seamlessly using short-lived tokens.

Why Avoid Static Service Account Keys?

Static service account keys present several operational challenges:

• No Automatic Expiration: Unless actively managed and rotated, keys remain valid indefinitely.
• Distribution Risk: Keys stored in code repositories or CI/CD secrets can inadvertently leak.
• Maintenance Overhead: Regularly rotating keys across dozens of applications requires substantial operational effort.

How Workload Identity Functions

Workload Identity establishes a trust relationship between your Kubernetes cluster and Google Cloud IAM through OpenID Connect (OIDC) federation.

Instead of reading a credential file mounted to the container:

1. The pod runs as a specific Kubernetes Service Account (KSA).
2. When the application uses a Google Cloud client library, it queries the local GKE metadata server.
3. The metadata server intercepts the token request and validates the pod’s identity using its projected Kubernetes service account token.
4. Google Cloud IAM verifies the relationship and returns a short-lived OAuth 2.0 access token for the linked Google Service Account (GSA).

[ Application Pod ] 
       │
       ▼ (Token Request)
[ GKE Metadata Server ] ──(OIDC Assertion)──► [ Google Cloud IAM ]
       ▲                                              │
       └──────── (Short-Lived Access Token) ──────────┘

Basic Configuration Pattern

The relationship is configured by linking the KSA to the GSA:

1. IAM Role Binding

Authorize the Kubernetes Service Account in your cluster to act as the Google Service Account:

gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"

2. Service Account Annotation

Annotate the Kubernetes Service Account so GKE knows which Google Service Account it corresponds to:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: KSA_NAME
  namespace: NAMESPACE
  annotations:
    iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Summary

Workload Identity simplifies credential management in Kubernetes by delegating token lifecycle and rotation to the platform. Understanding how the metadata server and IAM interact helps engineers build more reliable and maintainable cloud architectures.