Permissions in AWS are written down, as JSON, in policies. You met one in Chapter 1, on a bucket. The same grammar describes what a user, group or role may do.

The grammar

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListReports",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::monster-reports"
    },
    {
      "Sid": "ReadReports",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:GetObjectVersion"],
      "Resource": "arn:aws:s3:::monster-reports/*"
    }
  ]
}

A policy is a list of statements. Each has an Effect (Allow or Deny), one or more Actions written service:Operation, and one or more Resource ARNs. Sid is an optional label. Version is always that date.

Actions take wildcards: s3:Get* is every S3 read, s3:* every S3 operation, * everything. Resources take them too: arn:aws:s3:::monster-reports/* is every object in the bucket.

Bucket versus objects

The two statements above are not redundant. Listing a bucket is an operation on the bucket, so its resource is the bucket ARN. Reading an object is an operation on the object, so its resource ends in /key, usually /*. A read-only policy that forgets the second line can list but not fetch; one that forgets the first can fetch by exact name but not browse. Some operations have no resource at all, like s3:ListAllMyBuckets, and take Resource: "*".

Two kinds of policy

Dana's policy is identity-based. Chapter 1's bucket policy was resource-based, which is why it had "Principal": "*".

Making one

aws iam create-policy --policy-name ReportsRead --policy-document file://reports-read.json
aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/ReportsRead --version-id v1

create-policy turns the file into a customer managed policy with its own ARN. The next lesson explains how it, and the other kinds, get attached.