JSON service account keys on nodes or in secrets are a liability. Workload Identity lets pods exchange Kubernetes identity for Google IAM tokens with fine-grained bindings.
Enable Workload Identity on the cluster, create Google service accounts per workload class, and bind Kubernetes service accounts explicitly. Prefer least privilege over shared “runtime” accounts.
Combine with Binary Authorization or image policies and Network Policy for a stronger baseline. Monitor for pods still using legacy key mounts.
Secure GKE starts with identity—everything else is easier when pods stop carrying permanent keys.
Document the mapping from namespace/service account to GCP roles for auditors and on-call.
Use separate identities for read vs mutate paths when feasible.
Monitor failed token exchanges—they often reveal broken bindings before users feel an outage.
Key takeaways
- Prefer Workload Identity over JSON keys on nodes or in secrets.
- Bind Kubernetes service accounts to narrowly scoped Google IAMs.
- Rotate and review bindings when services change ownership.
FAQ
Do we still need Kubernetes RBAC?
Yes. Workload Identity covers Google API access; RBAC still controls what can happen inside the cluster.
What is a common misconfiguration?
Over-broad IAM on the Google service account, or enabling Workload Identity without removing leftover keys that remain valid.