Cloud Security In progress
Beginner 20 min read Cloud Security
Identity and Access Management Basics
Control who can touch what in the cloud: users, roles, policies, and least privilege as enforceable code rather than good intentions.
IAMrolespoliciesleast privilegeservice accountscredentials
Introduction
What is this?
Cloud IAM is the system of identities (human and machine), permissions (policies), and the mechanics to grant exactly the access each one needs, no more.
Motivation
Why do you need it?
- IAM is the number-one cause of cloud data exposure — an over-permissive role or exposed key is the story of most breaches.
- It is the control with the fastest blast-radius reduction: a least-privilege policy is cheaper than any breach response.
- Modern cloud security is fundamentally an identity game; everything else is a wall behind IAM.
Think about it
Mental model
Imagine
A building pass
Think of
A pass that opens every door, forever
You designed it for the employee of the month; you shipped it to everyone so you could skip keeping it updated.
Mechanics
How it works
- An identity (user, role, or service account) carries a policy: an allow/deny statement over actions and resources.
- AWS evaluates explicit deny before allow; Azure uses role assignments on scope; GCP binds roles to members (IAM policy).
- Roles abstract permissions from humans: 'EC2Operator' instead of a pile of raw actions, so people rotate through roles.
- Credentials (keys, tokens) give the identity legs; rotation and scoping limit how far a leaked key walks.
A least-privilege request evaluation
Actoruser/role/service account
Policyexplicit allows, deny by default
Scoperesource + action bound
Allownarrow, time-bound access
Auditevery decision logged
Real world
In production
- A fintech replaces a standing admin key with short-lived credentials via an IAM-linked service so rotation is automatic.
- A company roles out cross-account roles with 'read-only on one S3 bucket' grants instead of dumping full access.
- A startup's infra team uses Infrastructure-as-Code to review every IAM change as a diff in CI.
Guidelines
Best practices
- Default to deny and add the smallest allow; grant by role, not by person-copy.
- Prefer short-lived or federated credentials over long-lived access keys.
- Rotate keys on a cadence; revoke instantly on termination or compromise.
- Make IAM changes reviewed diffs, peer-reviewed, with a reason field.
Watch out
Common mistakes
- Creating one 'break-glass admin' key and reusing it for routine deploys 'temporarily'.
- Granting 'AdministratorAccess' to a service role because debugging is easier.
- Sharing a single service-account key across a team on the wiki.
- Never revoking: an offboarded employee's role still existing in the policy is a ticking bomb.
When things break
Debugging tips
- Use the provider's policy simulator/azure effective permissions to see why a request is denied.
- When 'it worked before', diff the last IAM change — those diffs are the smoking gun.
- Prefer the audit log to guesswork: every denial is recorded with the identity and action.
Security
Security considerations
- Treat a leaked key as compromised: rotate, revoke, and inspect what it could touch in the previous window.
- Machine roles should be least-privilege too — a container role with delete-everything is a P0 waiting.
Interviews
Interview checkpoint
Practice
Hands-on lab
Build a Least-Privilege Policy and Prove It in a Local Emulator
45 min · beginner
Objectives
- Write a policy that grants read-only on one bucket to a named role.
- Provision a local emulator (minio/localstack) and attach the role.
- Prove the role can read its bucket but cannot write or touch another.
Build a Least-Privilege Policy and Prove It in a Local Emulator
45 min · beginner
0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself
Quick quiz
0/2
1
The strongest protection against a leaked long-lived key is...
2
least privilege means...
Go deeper