Lion Cipher Lab
Reimplement the AWS IAM policy-evaluation engine from scratch
- Cloud Security
- Advanced
- ~90 min
- Free · no account required
Why it matters
The large majority of real AWS compromises are not exotic exploits -- they are identity misconfigurations: a policy that grants more than anyone intended, or a 'deny' someone assumed was in force but never was. The durable skill is not clicking 'deny' in the console; it is being able to reason precisely about WHY a given request is granted or refused, across identity policies, resource policies, SCPs and permissions boundaries at once. The single most expensive misconception in that reasoning is treating Allow as additive across every policy type -- as if attaching one more policy can only…
What you'll learn
- Implementing AWS's real policy-evaluation order (explicit-deny-wins, then ceilings, then allow)
- Reasoning about SCPs and permissions boundaries as subtractive ceilings, not additive grants
- Matching Action wildcards (s3:*, s3:Get*) and Resource ARNs with * and ?
- Implementing NotAction / NotResource and a minimal Condition evaluator (StringEquals and more)
- Producing a decision trace that names the statement responsible for the final verdict
- Stating honestly which parts of the real IAM engine a core model does and does not cover
Steps in this lab
- The question this engine answers
- The evaluation order, and why the order is the whole point
- Build the matchers: actions, ARNs, and conditions
- Build 'does this statement apply?'
- Build the core: eval_policies, ceilings, and the ordered authorize()
- Add a runner and four worked policy fixtures
- Run the four scenarios and read the real traces
- The judgment: why 'Allow is additive' is the costliest IAM myth
- Name the limits honestly: what this engine does NOT model