Google Cloud Workload Identity for Secure Authentication Without Keys

Overview

GKE Workload Identity lets pods call Google Cloud APIs using short-lived credentials tied to a Kubernetes service account (KSA), without having to store JSON service account keys in clusters. A mapping links each KSA to a Google service account (GSA); the metadata server exchanges Kubernetes tokens for access tokens scoped to the GSA’s IAM roles. This eliminates long-lived secrets from etcd and images, supporting least privilege and auditability expected under SOC 2, ISO 27001, and PCI DSS credential controls.

Introduction

Service account keys are static credentials. Embedded in Helm values or Secrets, they leak through Git, backups, and compromised nodes. Rotation is painful; leakage is hard to detect. Google recommends avoiding user-managed keys for workloads on GCP.

Workload Identity replaces keys with STS-backed identity: pods use the metadata server; Google returns tokens for the GSA. Workload Identity Federation extends the same model to AWS, Azure, and on-premises OIDC environments, without requiring keys in those environments.

This article covers GKE architecture, token flow, governance practices, and key migration.

Architecture Overview

• KSA: Namespace identity via serviceAccountName.
• GSA: IAM principal for Storage, Pub/Sub, Secret Manager, etc.
• Binding: KSA annotation gke.io/gcp-service-account=… plus roles/iam.workloadIdentityUser for member PROJECT.svc.id.goog[NAMESPACE/KSA].
• Metadata server: Token exchange when the cluster workload pool is enabled.
• Clients: Application Default Credentials via 254.169.254.

Architecture Diagram

Architecture Flow Explanation

1. Pod scheduling: Deployment sets serviceAccountName: billing-worker in namespace payments. The projected service account token is available under /var/run/secrets/kubernetes.io/serviceaccount/.
2. Credential request: The Google client library (or curl to the metadata server) requests an access token. No GOOGLE_APPLICATION_CREDENTIALS file is required when Application Default Credentials are used.
3. Token exchange: GKE validates the KSA against the cluster workload identity pool svc.id.goog. This pool name must match the cluster configuration exactly.
4. Impersonation: Security Token Service returns an OAuth2 access token whose identity is the GSA, provided roles/iam.workloadIdentityUser binds serviceAccount:PROJECT.svc.id.goog[payments/billing-worker] to that GSA.
5. API authorization: Cloud Storage, for example, evaluates IAM on the bucket for billing-gsa@prod.iam.gserviceaccount.com with roles scoped to projects/_/buckets/payments-exports rather than project-wide storage admin.
6. Audit and attribution: Data Access logs in the resource project list the GSA as principalEmail, which SIEM rules can correlate to the owning team via a GSA naming convention (wi-payments-billing@prod.iam.gserviceaccount.com).

Core Security / Governance Best Practices

1. Org policy: disableServiceAccountKeyCreation at org; rare folder exceptions only.
2. One GSA per workload class: Avoid one shared cluster GSA; use IAM conditions on resources.
3. Least privilege: Resource-scoped roles, not project editor.
4. Retire key mounts: Migration-only Secrets with expiry dates.
5. Namespace RBAC: Limit who can deploy pods using sensitive KSAs.
6. Minimal node GSA: Nodes only for logging/monitoring—not data APIs.
7. Centralized logging: Alert on CreateServiceAccountKey; sink IAM admin logs to security project.
8. No key rotation program: Monitor anomalous GSA usage in SIEM.
9. PCI DSS 3.5/8.2: Demonstrate no static keys in images when WI is enforced.
10. Multi-cloud federation: OIDC from AWS/Azure to GSA for hybrid fleets.

Operational Benefits

• Eliminates quarterly key rotation runbooks for application teams; token lifetime is minutes, managed by Google.
• GitOps without GCP keys in repositories.
• Namespace compromise does not impersonate other teams’ GSAs.
• IAM and Asset Inventory show KSA→GSA mappings for audits.
• Native ADC in Go, Java, Python without sidecars.

Common Challenges and Mitigations

Enterprise Implementation Recommendations

• Fleet standard: A shared Terraform module enables workload_pool on every GKE cluster, creates GSAs from an approved catalog, and outputs the KSA annotation teams paste into Helm charts. Application projects never receive serviceAccountKeyAdmin for developers.
• CI/CD: Pipelines outside the cluster should use Workload Identity Federation with GitHub Actions (google-github-actions/auth) or GitLab OIDC. The member principal is principalSet://iam.googleapis.com/projects/PROJECT/locations/global/workloadIdentityPools/POOL/attribute.repository/ORG/REPO—still no JSON keys in GitHub Secrets.
• Migration runbook: (1) Create GSA with least-privilege roles, (2) add workloadIdentityUser binding and KSA annotation, (3) deploy canary pod reading one object from Storage, (4) remove Kubernetes Secret volume mounting the key, (5) confirm audit logs show GSA principal only, (6) delete keys in console and verify org policy denies new keys.
• Compliance packet: For ISO 27001 A.10 and SOC 2 CC6.1, attach architecture diagrams and a sample audit log line showing the use of a short-lived token. For PCI DSS, map key prohibition to requirement 3.5 (protect keys against disclosure) and 8.3 (secure authentication).
• Operations: Run a monthly report of GSAs with active user-managed keys via Asset Inventory + IAM Analyser; escalate any key older than 90 days.

Conclusion

Workload Identity is the enterprise standard for GKE-to-GCP authentication: JSON keys leave the threat model, least privilege applies per GSA, and Cloud Audit Logs attribute API use is clear.

Drop a query if you have any questions regarding Workload Identity and we will get back to you quickly.