Lion Cipher Lab
Reimplement EKS IRSA web-identity trust evaluation from scratch
- Cloud Security
- Advanced
- ~90 min
- Free · no account required
Why it matters
IRSA (IAM Roles for Service Accounts) is how the overwhelming majority of production EKS workloads get AWS credentials: no long-lived access keys baked into a pod, just a short-lived signed token the pod trades for temporary role credentials. That trade is governed by a role TRUST policy, and trust policies are where the expensive mistakes live. The single costliest one is writing a trust policy that checks only the token's audience (aud) and forgets to pin the subject (sub) -- because then ANY service account in the entire cluster, in any namespace, can assume that role. It is a textbook…
What you'll learn
- Understanding how a Kubernetes pod assumes an AWS IAM role with NO static keys (AssumeRoleWithWebIdentity)
- Reading a projected ServiceAccount token as a JWT: iss, sub (system:serviceaccount:<ns>:<sa>), aud, exp
- Publishing a JWKS and verifying an RS256 JWT signature against it from scratch
- Implementing the STS trust checks in order: signature, expiry, issuer, then trust-policy Condition on aud and sub
- Recognising and fixing the confused-deputy failure: an aud-only (or sub=*) trust policy any pod in the cluster can assume
- Choosing between IRSA and EKS Pod Identity, and knowing when NOT to hand-roll trust evaluation
Steps in this lab
- The question this engine answers: how does a pod get AWS creds with no keys?
- Mint the projected ServiceAccount token: a signed JWT + a JWKS
- The trust policy, and the exact checks STS runs before it trusts a token
- Build the primitives: verify an RS256 signature, evaluate a condition
- Build the core: assume_role_with_web_identity with a decision trace
- Run six scenarios: watch the confused deputy, then pin sub to fix it
- The judgment: aud proves the cluster, only sub proves the pod
- IRSA vs EKS Pod Identity, and when NOT to hand-roll this