Lion Cipher Lab
Reimplement Azure Managed Identity Token Trust (Offline)
- Cloud Security
- Advanced
- ~90 min
- Free · no account required
Why it matters
Azure Managed Identity is how the overwhelming majority of Azure workloads get credentials without a secret in code: a VM, App Service, or container asks the local Instance Metadata Service (IMDS) for a token scoped to a RESOURCE -- storage, Key Vault, a database -- and the Azure platform vouches for the identity, returning a short-lived Entra-signed JWT the resource validates. That design removes the OIDC-to-STS federation step AWS needs, but it moves the whole security question onto two claims: the AUDIENCE (which resource the token is for) and the appid/oid (which managed identity holds…
What you'll learn
- Understanding how an Azure VM or app gets a credential with NO stored secret via Managed Identity and the local IMDS token endpoint
- Reading an Entra ID (Azure AD) access token as a JWT: iss (sts.windows.net/<tenant>), aud (the resource), appid/oid (which managed identity), tid, exp
- Publishing a JWKS and verifying an RS256 JWT signature against it from scratch
- Implementing the resource-side checks in order: signature, expiry, issuer (tenant), audience (this resource), then an RBAC allow-list on appid/oid
- Recognising the audience confused-deputy: a valid token minted for one resource replayed at another, and why the aud/resource binding stops it
- Naming and defending the SSRF -> IMDS token-theft path: the Metadata:true header guard, proxy/X-Forwarded-For rejection, egress controls, and least-privilege RBAC as blast-radius control
- Choosing between Azure Managed Identity, AWS IRSA, and the shared-node IMDS anti-pattern -- and knowing when NOT to hand-roll trust evaluation
Steps in this lab
- The question this engine answers: how does an Azure workload get a credential with no secret?
- Mint the Entra access token: a signed JWT + a JWKS
- Model the IMDS token endpoint -- and its Metadata:true anti-SSRF guard
- The resource-side checks, in the exact order they must run
- Build the primitive: verify an RS256 signature against the JWKS
- Build the core: validate_at_resource with a decision trace
- Run it: the SSRF probe, then six scenarios incl. the confused deputy
- The judgment: a signed token proves WHERE it came from, never WHO holds it
- Managed Identity vs AWS IRSA vs the shared-node IMDS anti-pattern -- and when NOT to hand-roll this