search by tags

for the user

adventures into the land of the command line

aws permission nuances

if you use/administer amazon web services, chances are you are using iam. identity and access management. amazon’s documentation on their services are awesome, but one note i kept for myself was this logic flow surrounding allowing and denying users or resources.

there’s a few ways you can control access to your stuff

you can use access control lists (ACLs), a list applied to a resource, specifying what user or group and actions are allowed on the resource

you can use IAM policies, an access policy that is applied to an account, user, group or role (the principle in aws terms), specifying what resources and actions they have been allowed or denied from

or specifically for S3, you can use bucket policies, a policy similar in structure to an IAM policy, only that the resource and user (principle in aws terms) are switched. meaning that the policy is applied to a resource rather than a user, and specifying which account/user/group/role has access

they are all just different ways of doing the same thing, controlling access. but take note, the above workflow diagram applies to each method, regardless of what combination of them you use

so from the diagram we know that it goes deny > allow > deny

1. say for example you have an account.
2. by default everyone except the account’s root user is denied access.
3. you create an IAM policy to allow ‘myuser’ to access ‘mys3bucket’ and can perform GET, LIST AND PUT actions on the bucket.
4. you then create an S3 policy and apply it to ‘mys3bucket’ denying the GET action on the bucket to user ‘myuser’.
5. you then create an ACL on the bucket allowing everyone:read actions on the bucket ‘mybucket’

in this scenario, ‘myuser’ can do all actions on the bucket ‘mybucket’ except the GET action

because deny > allow > deny logic is applied based on directives from all policies combined