Stop 07 · Identity & SecurityTopics · 1/10

Identity & Access Management (IAM)

In short

Every click in the cloud console and every API call from your code asks one question first: who are you, and are you allowed to do this? IAM is the system that answers.

The system controlling who (or what) can do what within your cloud account — policies, roles, and permissions govern access to every single resource, making IAM arguably the single most important security surface in the cloud.

The blob character at a gate desk hands a coloured pass to a student.

Think of it like this

The hostel gate register

The warden checks your ID, then looks at your pass. A day pass lets you out till 9 p.m. A home pass lets you leave for the weekend. No pass, no exit. IAM checks identity first, then the permissions attached to it.

Watch it happen

One API call, two checks

Your script

AWS IAM

S3 bucket

signed request

1/6The CLI signs every request with your access key, so AWS knows exactly which identity sent it.

The big ideas

What you need to know

Principals

Anything that can make a request: a human user, a role used by a server, or another AWS service.

Policies are JSON

A policy lists Effect (Allow or Deny), Action (like s3:GetObject) and Resource (which bucket or table).

Deny by default

With no matching Allow, the answer is no. An explicit Deny always beats any Allow.

Every cloud has it

AWS IAM, Google Cloud IAM and Azure RBAC with Entra ID all follow the same who, what, where idea.

See it in code

Walk through the code

json

1{2  "Version": "2012-10-17",3  "Statement": [4    {5      "Effect": "Allow",6      "Action": ["s3:GetObject", "s3:ListBucket"],7      "Resource": [8        "arn:aws:s3:::college-reports",9        "arn:aws:s3:::college-reports/*"10      ]11    }12  ]13}

1/3The policy grammar version. Always use this exact string.

A read-only policy for one bucket. "2012-10-17" is the policy language version, not a date you should change.

Save yourself the pain

Common mistakes

Oops

Doing daily work while logged in as the root account.

Do this instead

Lock root away with MFA. Create a separate admin identity and use that, or better, SSO.

Oops

Writing "Action": "*" because the specific action name was hard to find.

Do this instead

Look up the exact action in the service's docs, or use IAM Access Analyzer to generate a policy from real activity.

Your mission

Read-only and proud of it

~30 min

Quick check

A user has one policy allowing s3:* and another explicitly denying s3:DeleteObject. Can they delete files?

Go deeper

1Create an IAM user with limited permissions instead of using a root/admin account for daily work.
2Write a basic IAM policy granting access to only a specific resource type.
3Learn why root account credentials should be locked away and rarely, if ever, used directly.