Lion Cipher Lab

Reimplement Google Cloud IAM policy evaluation from scratch (offline)

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

Why it matters

Ask a room of cloud engineers 'who can read this bucket?' and most will open the bucket's permissions page. On Google Cloud that answer is almost always wrong, because access to a bucket is not stored on the bucket -- it is the result of an EVALUATION over a hierarchy. A binding made once at the organization node grants on every folder, every project and every resource beneath it, forever, and nothing on the bucket's own page mentions it. Layered on top are three things that behave nothing like their AWS equivalents: allow policies contain no Deny at all (denial is a separate object, IAM deny…

What you'll learn

• Modelling the Google Cloud resource hierarchy (organization -> folder -> project -> resource) and resolving access by walking a resource up to the org
• Implementing allow-policy inheritance as a UNION of bindings across every ancestor node, and seeing why an org-level binding grants on every project
• Implementing IAM deny policies as a separate object evaluated FIRST, with deniedPrincipals, exceptionPrincipals and deniedPermissions
• Writing a small, SAFE evaluator for IAM Condition (CEL) expressions -- resource.name.startsWith and request.time windows -- without ever calling eval()
• Expanding basic vs predefined vs custom roles into permission sets, and quantifying why roles/owner and roles/editor are the classic GCP over-permission
• Distinguishing organization policy constraints (a configuration guardrail that inherits down the hierarchy) from IAM (who may act), and proving a project owner cannot grant around one
• Computing a principal's EFFECTIVE permissions as the transitive closure over service-account impersonation, and finding a privilege-escalation path a direct-bindings audit misses
• Knowing when to stop hand-rolling and reach for Policy Troubleshooter, Policy Analyzer and gcloud get-iam-policy instead

Steps in this lab

1. The question this engine answers: why 'who can read this bucket?' is not a lookup
2. Set up: one folder, one file, no installs
3. Model the resource hierarchy, and write the walk from a resource up to the org
4. Roles are bags of permissions: basic vs predefined vs custom
5. IAM Conditions: a small SAFE evaluator, and why you must never eval() one
6. Allow policies: bindings attached at nodes, inherited downward, unioned
7. Deny policies: the separate object, evaluated FIRST
8. The ordered pipeline: deny -> allow union -> decision, with a printed trace
9. Organization policy constraints: the guardrail layer that is NOT IAM
10. The headline: effective access is a transitive closure over impersonation
11. Run it: six requests, six different deciding rules
12. The judgment: put the deny policy and the constraint at the FOLDER, not the project
13. GCP vs AWS, and why you must never ship this engine

Open the full interactive lab →