3 ms·
It's honestly going to depend. In some cases you don't really have a choice. For example if you want to limit an S3 bucket to an IAM group, since S3/Resource
by colemorrison 10y ago
It's honestly going to depend. In some cases you don't really have a choice. For example if you want to limit an S3 bucket to an IAM group, since S3/Resource Policies don't support IAM groups ARNs in the principal, the only solution is to apply the permissions around access to that S3 bucket to the IAM group (as opposed to the bucket).
As for which direction, this is going to be a bit of preference and need. Do you want permissions to begin at the user or at the resource? For scenarios, like a bucket controlling access to non-aws users, it makes sense to have it on the resource. For others, like delegating bucket access to certain EC2 instances, it makes more sense to keep it on the role user.
The fuzzy lines of gray are only exaggerated by the fact that the docs love doing stuff like: "These two policies are equivalent!" And showing examples that accomplish both.
Tl;dr, (a) pick the permission direction that makes sense (b) set a standard for your team and infrastructure and stick with it (c) try to not use NotVersions of actions
- ecesena 10y agoThese recommendations are great, and for us the direction is definitely everything on roles. I was curious to see what others do concretely.
- devonbleak 10y agoWe have both out of necessity. IAM policies on roles/users/groups are a given, but here are some concrete examples of what we're using resource policies for: - Granting cross-account access to resources without requiring an explicit sts:AssumeRole on the other side (in some cases for things like CloudTrail and billing reports this is the only option) - Enforcing SSE on S3 buckets (implemented as a DENY in the bucket policy with conditions to check for missing SSE headers)