IAM at a glance — users, roles, service accounts

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.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain IAM users vs roles vs service accounts like I'm new to it, with a concrete example of when each is the right tool.

2. Why it works (the mechanism)

Walk me through how an EC2 instance with an attached IAM role actually obtains and rotates credentials step by step — from the metadata service IMDSv2 call to the temporary STS token in memory.

3. Advanced — application & what's next

Given a CI/CD pipeline in GitHub Actions that needs to deploy to AWS, Azure, and GCP without storing any long-lived secrets, design the federated identity setup for all three.

References

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