Who Can Do What: Cloud Identity Basics (IAM)

Why this matters

Every cloud has the same three primitives — humans, workloads, and the policies that bind them — but each calls them something different and each has a slightly different evaluation order. Get IAM wrong and either nothing works (deny-by-default) or everything is exposed (over-broad wildcard policies). Modeling identity correctly on day one saves you a security incident on day 200.

Demo

Create a least-privilege identity for a workload on each cloud and verify it can do exactly one thing.

Try it yourself

1. Create the AWS role and run simulate-principal-policy for s3:GetObject (allowed) and s3:DeleteObject (denied) — confirm the simulator shows the right answer for each.
2. On GCP, list the IAM bindings for your project and identify any role that ends in /owner or /editor — these are over-broad and should be replaced with predefined or custom roles.
3. Read your provider's docs page on assume-role (AWS) or workload identity federation (GCP) and write a one-sentence summary of how a CI runner would authenticate without a long-lived key.

References

• AWS IAM — Best practices
• Google Cloud — IAM overview