IAM policies are things that can be attached to an IAM identity to grant or deny access to resources.
- A policy specifies allow or deny rules
- A policy is only in effect when attached to IAM identities
- identity-based policy: policies consider actions for different resources, can be attached to one or more identities
- version: a date
- statement: grants/denies permission to identities
- Sid: name of statemetn
- Resource: ARN required (or just
*), the specific resource at hand (s3 or s3 bucket, or s3 bucket keys), wildcard allowed - Action: what actions are being considered on the resource, wildcard allowed
- Effect: whether to allow or deny the action towards the resource
- what happens if policies/statements overlap or conflict? deny, allow, deny
- explicit denies will be prioritized over anything else
- If there are two contradicting policies/statements for the same resource and action, the deny will be priotized.
- explicit allow is the next in row for priority
- default deny (implicit) is the catch-all when no policies/statements concern the resource/action at hand.
- explicit denies will be prioritized over anything else
- policy types
- inline policy: apply a policy to each individual account/users
- should only be used for special circumstances
- most of the time a bad practice: isolated JSONs, hard to coordinate and automate change
- managed policy: standalone object that can be attached to accounts/users
- reusable
- go-to policy type
- AWS-managed policies (stock policies created by AWS) vs custom managed policy (custom policies created in account)
- inline policy: apply a policy to each individual account/users