Difference between revisions of "Workload Identity Federation"

From wikieduonline
Jump to navigation Jump to search
Line 1: Line 1:
 
https://docs.cloud.google.com/iam/docs/workload-identity-federation
 
https://docs.cloud.google.com/iam/docs/workload-identity-federation
  
 +
Lets Kubernetes pods authenticate to GCP APIs using a distinct, scoped GCP service account per workload, instead of the node's shared one.
 +
* Replaces the old model where every pod on a node inherited the same broad [[oauth_scopes]] identity.
 +
* Uses short-lived tokens tied to an explicit KSA→GSA binding — no static keys stored anywhere.
 +
* Limits blast radius: a compromised pod only has its own workload's permissions, not everything the node can do.
 +
* Enabling it (via GKE_METADATA mode) also blocks the old fallback path — so any pod without an explicit binding now gets no GCP access at all.
 +
 +
== Related ==
 
* [[OAuth 2.0 token exchange]]
 
* [[OAuth 2.0 token exchange]]
  

Revision as of 09:08, 16 July 2026

https://docs.cloud.google.com/iam/docs/workload-identity-federation

Lets Kubernetes pods authenticate to GCP APIs using a distinct, scoped GCP service account per workload, instead of the node's shared one.

  • Replaces the old model where every pod on a node inherited the same broad oauth_scopes identity.
  • Uses short-lived tokens tied to an explicit KSA→GSA binding — no static keys stored anywhere.
  • Limits blast radius: a compromised pod only has its own workload's permissions, not everything the node can do.
  • Enabling it (via GKE_METADATA mode) also blocks the old fallback path — so any pod without an explicit binding now gets no GCP access at all.

Related

See also

Advertising: