Lion Cipher Lab

Reimplement S3 bucket-policy + Block Public Access evaluation from scratch

• Cloud Security
• Advanced
• ~90 min
• Free · no account required

Why it matters

The publicly-exposed S3 bucket is the signature breach of the cloud era, and almost none of those leaks were exotic -- a bucket policy said Principal "*" and nobody ran the evaluation that would have told them the whole internet could read it. In the prerequisite lab you reimplemented the IDENTITY side of AWS authorization: identity policies and permissions boundaries, the half that answers 'what is THIS caller allowed to do?' But an S3 object request is also judged by the RESOURCE: the bucket's own policy, which -- unlike an identity policy -- names a Principal and can therefore hand access…

What you'll learn

• Reimplementing the RESOURCE side of S3 authorization: a bucket policy's Principal (anonymous "*", cross-account, and same-account), matched against a real request
• Encoding the rule that explicit Deny in a bucket policy wins over every Allow, independent of Block Public Access
• Deciding when a bucket policy is 'public': a Principal:* Allow with no restricting Condition -- and why a fixed cross-account grant or a fixed-value Condition is NOT public
• Modelling Block Public Access: RestrictPublicBuckets neutralises a public policy at evaluation time while BlockPublicPolicy rejects it at PUT time, and effective BPA is the most-restrictive OR of bucket-level and account-level flags
• Measuring exactly which requests flip from ALLOW to DENY once account-level BPA is turned on -- and which do not (the owner account keeps access; true-negatives were never public)
• Stating honestly what this resource-side model does NOT cover (ACLs in full, Access Points, VPC endpoint policies, Object Ownership) and how it composes with the identity-side prereq lab

Steps in this lab

1. The question this evaluator answers -- and how it differs from the IAM lab
2. Every term, defined once: Principal, anonymous, cross-account, public, and the four BPA flags
3. Build the matchers: action, resource, Principal, and a minimal Condition
4. Build the public determination, the BPA overlay, and the ordered authorize()
5. Add five worked fixtures and a runner that measures the flips
6. Run it with BPA OFF: a bucket that LOOKS locked is public via policy
7. Run it with BPA ON: the public grant neutralised, and MEASURE the flip
8. The judgment: 'is it public?' is a determination, not a grep
9. Name the limits honestly: what this resource-side model does NOT cover
10. What you built -- and the two halves you now hold

Open the full interactive lab →