Lion Cipher Lab

Review every IAM role trust policy in an AWS account: who can assume what, and which trusts are too wide

Why it matters

An IAM role is a key to your AWS account, and its trust policy is the list of who is allowed to pick that key up. Most accounts collect dozens of roles over the years: one for every server, every function, every vendor integration, every CI pipeline and every person who signs in through the company login. Each trust was written by someone different, on a different day, under a different deadline. The dangerous ones look harmless: a vendor role with no ExternalId, a GitHub Actions role that trusts every repository on GitHub, an old contractor account nobody remembers. Attackers do not need to…

What you'll learn

Steps in this lab

  1. What a role trust policy is, in plain words
  2. Two halves of access, and the one same-account exception
  3. Get set up (from zero)
  4. Where the real data comes from: get-account-authorization-details
  5. Build a synthetic account with 44 roles and an answer key
  6. The seven rules, and the document each one comes from
  7. Write the reviewer
  8. Run the review and read the findings table
  9. Score the reviewer: true positives, false positives, and the naive baseline
  10. Write the fixes as corrected trust JSON
  11. Rerun on the fixed export: zero HIGH, zero MEDIUM
  12. Cross-check: IAM Access Analyzer does part of this natively
  13. Honest limits: what this review does not tell you
  14. How a pro runs this for real

Open the full interactive lab →