Least-privilege policies

What a tight policy actually looks like

Least privilege is one rule: a principal should hold exactly the permissions required to do its job, for exactly as long as it needs them — and not one permission more. The hard part isn’t the principle, it’s that the convenient policy and the correct policy look almost identical, and the convenient one ships faster.

An IAM policy answers two questions for every request: which actions (s3:GetObject, dynamodb:Query) and on which resources (a specific bucket ARN, a specific table). A tight policy names both. The service that reads one config object should hold this:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::acme-config/service-x/*"
}

One action, one resource prefix. If that key leaks, the attacker gets read access to one folder in one bucket — a contained, boring incident. The blast radius is the policy, and you wrote the policy small on purpose.

The reflex to build is: start from deny, add the single action you can name, scope it to the single ARN you can name, and stop. Every time you reach for a *, you are saying “I don’t know which actions or resources this needs” — and an attacker who steals the credential knows exactly what to do with that uncertainty.

Why wildcards bite

Wildcards are the default failure mode because they are genuinely useful while you’re building and genuinely dangerous once you ship. There are two wildcards, and both hurt.

Action: "s3:*" widens what the principal can do. The service needed GetObject; the wildcard also handed it PutObject, DeleteObject, PutBucketPolicy, PutBucketAcl. Now a read credential can overwrite your data, delete it, or make a private bucket public. Resource: "*" widens where it applies — from one bucket to every bucket, including ones that don’t exist yet. The two compose: s3:* on * is full control of your entire object store from a credential that was provisioned to read a config file.

There’s a quieter cost too: wildcards make audit impossible. When a policy says s3:GetObject on a named ARN, a reviewer can read it and know precisely what the role can do. When it says s3:* on *, the only honest answer to “what can this role do?” is “everything to everything” — and nobody can reason about a blast radius that large. Tight policies are self-documenting; wildcards erase the documentation.

Permission boundaries: the guardrail least privilege needs at scale

Writing one tight policy is easy. Keeping every policy tight, across hundreds of roles and dozens of engineers who all have the power to create roles, is the real problem. This is what permission boundaries solve.

A permission boundary is a policy attached to a principal that sets the maximum permissions it can ever have — a ceiling, not a grant. The principal’s effective permissions are the intersection of its identity policies and its boundary: a permission is allowed only if both permit it. So even if a developer (or an attacker who has compromised that developer’s role) attaches AdministratorAccess to a new role, the boundary clips it back down to whatever the boundary allows.

The canonical use is delegated role creation. You let developers create roles for their own services — that’s good for velocity — but you require that every role they create carries a boundary you control. Now a developer can grant their service s3:GetObject on their bucket, but they cannot create a role with iam:* or access to the production database, because the boundary forbids it and the intersection wins. The boundary turns “trust every engineer to write a perfect policy” into “trust the one boundary policy, and let engineers move fast inside it.”

A boundary is not a substitute for tight policies — it’s a backstop. The identity policy is where you express intent (this role reads config); the boundary is where you express limit (no role in this account may ever touch IAM or prod data). You want both: tight policies so the common case is correct, and a boundary so a single sloppy policy can’t become an account compromise.

Reviewing a policy like a senior

When a policy crosses your review, you’re scanning for three things in order. First, wildcards: any Action: "*", "s3:*", or Resource: "*" is a question, not necessarily a bug — but it must be justified, and “it was easier” isn’t a justification. Second, the dangerous verbs: iam:*, iam:PutRolePolicy, iam:PassRole, sts:AssumeRole on a broad resource, *:Delete*, anything that can change other permissions or destroy data. Third, resource scope: does each statement name the specific ARNs it touches, or does it leave Resource: "*" because nobody enumerated them?

The senior move is to drive policies down over time, not just gate new ones. Cloud providers expose access-analyzer / last-accessed data: which actions a role has actually used in the last 90 days. A role granted s3:* that has only ever called GetObject and ListBucket is telling you its real policy — generate the tight one from observed usage and replace the wildcard. Least privilege isn’t a one-time grant you get right at creation; it’s a ratchet you tighten as you learn what the role actually does.