IAM Policies
Inkwell's developers need to upload book covers to the inkwell-covers bucket and read them back. Last month someone deleted two hundred covers by mistake, so this time deleting must be impossible. Groups say who; policies say what exactly they may do.
The rule
Deny wins; then allow; otherwise, no.
A policy is a JSON document of statements:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::inkwell-covers/*"
},
{
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::inkwell-covers/*"
}
]
}- Effect:
AlloworDeny. - Action: API operations, written
service:Operation. Wildcards work:s3:*means every S3 action. - Resource: which things, named by ARN (Amazon Resource Name).
arn:aws:s3:::inkwell-coversis the bucket;arn:aws:s3:::inkwell-covers/*is every object inside it. - Condition (optional): extra tests, such as requiring MFA or a source IP range.
- Version is always
"2012-10-17", the current policy language, not today's date.
When a request arrives, AWS gathers every policy that applies and decides in a fixed order:
- Any explicit Deny that matches → denied, no matter what else says.
- Otherwise, any Allow that matches → allowed.
- Otherwise → denied. This default is called the implicit deny.
Policies attached to users, groups and roles are identity-based. Policies attached to a resource, such as an S3 bucket policy, are resource-based and name a Principal, the who. You will write one of those in the S3 section.
Policies also come in two packagings. Managed policies stand alone and can be attached to many identities: AWS publishes ready-made ones such as ReadOnlyAccess, and you can write your own. Inline policies are embedded in a single identity and are deleted with it. Prefer your own managed policies that grant only the actions the job needs: the principle of least privilege.
The shortcut
Evaluate every request with the three-line check: Is there a matching Deny? Is there a matching Allow? If neither, it is no. Stop at the first yes.
Any matching Deny?
Yes:
s3:DeleteObjectoninkwell-covers/*. Stop. Denied.
The trap is the resource ARN. Listing a bucket acts on the bucket ARN (no /*), while reading objects acts on the object ARN (with /*). A policy with only one of them grants only half of what you meant.
Drills
Answer fast — trust the rule.
A request matches no Allow and no Deny statement. What happens?
One policy allows s3:* on the bucket; another explicitly denies s3:DeleteObject. Can the user delete an object?
Which ARN names every object inside the inkwell-covers bucket?
What does "Version": "2012-10-17" in a policy mean?
Which kind of policy contains a Principal element?
Remember
- Deny wins; then allow; otherwise, no.
- Statements are Effect, Action, Resource, optional Condition; resource policies add Principal.
- Trap: the bucket ARN and the object ARN (
/*) are different resources.