Guides

Cloud IAM Least Privilege

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Cloud IAM least privilege means every human and workload identity gets only the actions and resources required for its job — nothing more — with MFA for humans, short-lived credentials for machines, and audit logs that prove who did what. Wide *:* admin policies are convenient until one key leaks; Capital One–era lessons still apply.

Identity → Authentication (MFA) → Authorisation (least privilege) → Audit
*:* admin = blast radius = entire account
Keys in git = incident waiting

What do I need before this guide?

• Optional AWS IAM MFA guide: Create IAM user with MFA.
• Optional: Attach IAM role to EC2.
• Basic idea of cloud shared responsibility.

What does least privilege look like?

1. Identity — who (user, role, service principal).
2. Authentication — prove it (password + MFA, federation, workload identity).
3. Authorisation — allowlist of actions on specific resources.
4. Boundary / SCP / org policy — guardrails even administrators struggle to bypass casually.
5. Audit — immutable-ish logs of API calls and console sign-ins.

Educational warning: practise IAM tightens in accounts you own. Do not “test deny policies” on a shared company prod account without change control — you can lock teams out.

Real incident: Capital One (2019) — cloud identity and misconfiguration themes

Public reporting on the Capital One 2019 breach described a misconfigured web application firewall / SSRF-style path leading to abuse of cloud metadata credentials and broad data access themes. The lasting blue-team lesson: instance roles and metadata, over-permissive IAM, and detection of unusual cloud API usage must be first-class controls — not afterthoughts.

Takeaways (vertical):

1. What happened — cloud-hosted data exposure with identity/credential pathways in public analyses.
2. What went wrong (theme) — excessive role permissions and insufficient guardrails around metadata / SSRF classes of bugs.
3. Care-take — scope instance roles to exact S3 prefixes / APIs needed.
4. Care-take — monitor CloudTrail for strange s3:List / credential-like patterns from web tiers.
5. Care-take — IMDSv2-style hardening themes reduce casual metadata theft (follow current AWS guidance).
6. Bonus parallel — countless breaches start with a leaked AKIA… key pushed to a public repo.

Humans vs workloads (do not mix)

1. Humans: SSO + MFA + time-bound elevation for admin tasks.
2. Workloads: roles assumed by compute — no shared “deploy user” password.
3. Contractors: separate accounts or permission sets; expiry dates on access.
4. Automation: prefer OIDC from GitHub Actions / GitLab to cloud roles over static keys.
5. If you must use keys: minimum actions, short rotation, never on developer laptops long-term.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Phish console passwords; bypass MFA fatigue where possible.
• Steal long-lived keys from CI logs, images, chat pastes.
• Abuse over-broad roles reachable from a single web foothold (high-level).

Blue Team — defend, detect, respond

• MFA everywhere humans exist; passkeys where supported.
• Short-lived federation (SSO) over permanent IAM users when possible.
• Permission boundaries; remove unused actions with access analyser-style tools.
• Alert: root login, Disable CloudTrail, AttachUserPolicy of Admin, CreateAccessKey surprises.
• Rotate and delete unused keys; never embed keys in AMIs.

How do I apply least privilege step by step?

Step 1 — Inventory identities

1. List human users, groups, roles, service accounts.
2. Flag anything with Administrator / Owner equivalents.
3. Flag access keys older than your policy (for example 90 days).

Step 2 — Split duties

1. Billing ≠ security admin ≠ app deploy roles when the org is large enough.
2. Developers get deploy roles to their namespaces / accounts — not org-wide IAM full control.
3. CI systems get OIDC federation to cloud roles — not a static key in a variable if you can avoid it.

Step 3 — Write a narrow policy (AWS-shaped example)

Illustrative deny-by-omission idea (not a paste-blind into prod):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": ["arn:aws:s3:::learnfast-app-uploads/*"]
  }]
}

Contrast with "Action":"*","Resource":"*" — that second shape is a lab convenience, not a production lifestyle.

Step 4 — Attach to roles, not forever-users

1. EC2 / ECS / Lambda assume a role.
2. Humans assume roles via SSO permission sets.
3. Document why each Action exists in a one-line comment in the repo that stores IaC.

Step 5 — Detect misuse

1. CloudTrail (or Azure Activity / GCP Audit) on and centralised.
2. Alerts for policy changes, root usage, unusual regions, mass ListBuckets.
3. Correlate with identity provider sign-in risks.

Step 6 — Review cadence

1. Quarterly: unused roles, unused actions, stale keys.
2. After every incident: shrink the role that hurt you.
3. Tabletop: “CI key leaked on GitHub — revoke path in 15 minutes?”

Care-take — habits that shrink blast radius

1. No root API keys; root MFA; root in a sealed process.
2. SCP / org policies block leaving org, disabling security services (where available).
3. Secrets in a manager — not in userdata plaintext.
4. Separate prod / non-prod accounts.
5. Break-glass with alarms.
6. When an employee leaves: SSO disable first, then cloud keys.

How do I fix common IAM mistakes?

Ghabru naka 😅 — these are the usual ones: