Policies: the permission language

What a policy looks like

"Give Ben read access" is too vague for a computer to enforce: which files, which actions, forever or until when? IAM needs permissions written in an exact, checkable form, and that form is what you will actually read at work — the first step in debugging almost every AccessDenied error is opening a policy document.

A policy is that document: JSON attached to an identity. It is a list of statements, and each statement has three core parts:

• Effect: Allow or Deny
• Action: what API calls, like s3:GetObject (read a file from S3)
• Resource: what things, named by ARN (Amazon Resource Name), a globally unique ID like arn:aws:s3:::my-app-photos/*

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

Read it aloud: this identity may read and write objects, but only inside the my-app-photos bucket. That is least privilege from lesson 2-1 written down.

The three evaluation rules

When a request arrives, IAM gathers every policy attached to the identity and applies three rules, in order:

1. Default deny. With no policies at all, the answer is no.
2. An explicit Deny always wins. If any statement denies the action, it is denied even if ten others allow it.
3. Otherwise, one Allow is enough.

That is the whole algorithm. Explicit denies exist as guardrails: a company can attach deny deleting databases in production to everyone, and no allow anywhere can override it.