IAM
Intermediate 15 min read IAM

Least Privilege Design

Give exactly the access a job needs

Least privilege grants the minimum permissions a workload needs. It's implemented with resource scoping, condition keys, short-lived credentials, and aggressive use of deny-defaults — then enforced with monitoring.

least privilegescopingcondition keysdeny by defaultaccess analyzerjeproduce
Prerequisites: Roles and Policies
Before we start

What you will learn

  • Scope permissions by resource, action and condition
  • Use condition keys (MFA, IP, OIDC) to narrow further
  • Maintain least privilege with tools and review
In 60 seconds

Least privilege = scoped actions on scoped resources with scoped conditions. Default-deny identity; add only the perimeter of a workload's real calls; use access analyzers and quarterly reviews to catch creep.

Introduction

What is this?

Least privilege means each identity can do every action it legitimately needs and nothing more. Implementation: narrow Actions (deny wildcard admin), narrow Resources (ARN/tag/prefix), add Condition keys (MFA, source IP, OIDC subject, resource tags), use short-lived credentials, and default-deny. Tooling: AWS IAM Access Analyzer, Azure AD/AZTU unecessary permissions insights, GCP Recommender + access analysis. Policies are code; CI lints 'too broad' shapes.

Motivation

Why do you need it?

  • Blast radius: a stolen dev key can't touch prod if dev is scoped.
  • Compliance (SOC 2, HIPAA) audits ask for evidence of least privilege.
  • Broad permissions hide secrets: 'temporary admin' become permanent admin.
  • Operational: narrow policies fail at the exact action, making debugging precise.
Think about it

Mental model

Imagine

A bank clerk with a limited drawer and a manager with the vault

Think of

Least privilege

The clerk can process deposits under $10k; the manager overrides with MFA and dual-control. You don't give the clerk the vault combination because one day they might need it — you give them a raised limit when justified.

Mechanics

How it works

  • Start deny-all: enumerate a workload's actual API calls (or logs) and allow exactly those.
  • Scope Resources to the ARNs/tags/prefixes the workload touches.
  • Add Conditions: RequireMFA, SourceIp, ResourceTag, aws:PrincipalTag, oidc:sub.
  • Prefer ephemeral: roles assumed with short TTL over long-lived keys.
  • Review periodically: Access Analyzer/Insights flag unused roles, overly broad grants, unused keys.

Narrowing permissions down to actual use.

Wildcards
Action scoping
Resource scoping
Conditions
Short-lived creds
Real world

In production

  • CI OIDC roles pinned to repo+branch so PRs can't assume deploy.
  • Data engineers read one bucket prefix; a separate role writes to staging.
  • Production keys are session-scoped with MFA and SourceIp conditions.
Guidelines

Best practices

  • Think in verbs+objects: 'GetObject on acme-data/import/*' not 'S3 full'.
  • Automate: Access Analyzer/Recommender feeding PR reviews.
  • Prefer short-lived STS/sessions everywhere over static keys.
  • Combine with break-glass: emergency admin requires approval and MFA.
Watch out

Common mistakes

  • Wildcards everywhere because it's 'simpler' (it's not — debugging != simple).
  • Copying a full admin policy and trimming one action sometimes.
  • Static access keys lying around for years.
  • Grants by role-name without resource scoping, so anything in that ARN matches.
Root cause analysis

Common issues

Error
App fails on an action you thought was allowed
Root cause

Resource ARN or condition (tag/IP) mismatch

Fix

Enumerate the failing API's ARN and add a precise condition.

Error
Principal uses wildcards and a demo turns into prod admin
Root cause

Policy perpetuates breadth

Fix

Refactor to scoped policies via Access Analyzer suggestions and CI gates.

When things break

Debugging tips

  • Audit effectively: list who can assume what and mark every wildcard action.
  • When an app needs a permission, add exactly that permission, not 's3:*'.
  • Use condition keys to explain 'why this party, why now'.
  • Rotate and revalidate keys quarterly with an automated expired-key job.
Interviews

Interview checkpoint

Practice

Hands-on lab

Scope a Policy Down with Conditions
30 min · advanced
In progress
Objectives
  • Compare broad vs conditioned policies
  • Use a condition (MFA/IP) to narrow
  • Simulate allow/deny outcomes

Scope a Policy Down with Conditions

30 min · advanced

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which makes a policy least-privileged?

2

Least privilege means every identity gets exactly the access its job needs.

Go deeper

Official documentation

AWS — IAM Access Analyzer
docs
Azure — Review role assignments
docs
GCP — Recommender for IAM
docs