s0sta
EN NL عربي
Filters
How to search
  • Plain words find names, texts and examples.
  • "two words" finds the exact phrase.
  • --name or -x finds an option.
  • #word looks only inside commands.
  • @grep finds lessons and labs that use grep.
  • Filters: cat:network · in:labs · in:notes · level:rhcsa · ch:8 · root:yes. Put ! before a word to leave it out. OR between words means one of them.
  • ↑ ↓ to move · Enter to open · Esc to close · / to search

DevSecOps & cloud securityPlatform series

IRSA vs GKE Workload Identity vs Azure Workload Identity

IRSA, GKE Workload Identity and Azure Workload Identity solve one problem: a pod needs a cloud credential, and a static key is not acceptable. All three exchange a Kubernetes service account token for short-lived credentials.

Quick reference

IRSAGKE WIAzure WI
MechanismOIDC token to STSOIDC token to IAMOIDC token to Entra
Trust anchorEKS OIDC providerGKE workload poolAKS OIDC issuer
ScopePer service accountKSA to GSAPer federated cred
Setup🟡 Role, trust, annotate🟡 Binding, annotate🟡 Credential, annotate
Portability❌ AWS only❌ GCP only❌ Azure only
Best for✅ EKS clusters✅ GKE clusters✅ AKS clusters

How to pick

  • IRSA → the EKS way: a KSA annotated with an IAM role.
  • GKE → map a KSA to a Google service account.
  • Azure → federate a KSA with a managed identity.

Explained

Mechanism and trust

Each pod gets a projected token for its Kubernetes service account. The cloud STS validates it against the cluster's OIDC issuer and returns temporary credentials. No secret is stored in the pod. The trust anchor is what differs. IRSA trusts the EKS cluster's OIDC provider. GKE trusts the workload identity pool of the project. Azure trusts the AKS cluster's OIDC issuer through a federated identity credential.

Scope and setup

IRSA maps one Kubernetes service account to one IAM role. GKE maps a KSA to a Google service account with an IAM binding. Azure maps a KSA to a managed identity through a federated credential. Setup has the same shape everywhere: enable the cluster issuer, create the cloud identity, annotate the Kubernetes service account.

Portability and fit

None of them ports. The annotation key, trust policy and token audience are provider-specific, so moving cloud means rebuilding the identity layer. Each is native to its cluster: IRSA on EKS, Workload Identity on GKE, federated identity on AKS. Use the managed option, not a custom token broker.

The honest caveat: the trust policy is the security boundary. A wildcard subject or audience lets any service account in the cluster assume the role.

The lesson: the mechanism is portable; the trust anchor is not.

In one line

One identity, three clouds. The mechanism is the same; the trust anchor is not.

Check the issuer

aws eks describe-cluster --name prod

More notes: DevSecOps & cloud security

Open in the notes app: search, filters, copy This note on GitHub