RFC: Should iamy manage S3 bucket policies

[mtibben]

Should iamy also manage S3 bucket policies? Is that in-scope for a tool like this?

I'd be keen to hear the thoughts of people using this tool /cc @lox @pda @simpsora @SomeoneWeird @joho

We typically use roles to manage cross-account access, however it's sometimes convenient to use S3 bucket policies to allow a user in a different account direct access to a bucket. Because you are granting access to users, it works in a complementary way with an IAM user policy.

If iamy were to manage bucket policies, it also raises the question whether we should manage bucket ACLs also? I lean towards no - bucket policies can achieve everything bucket ACLs can, and ACLs apply to both buckets as well as objects in the bucket - it seems out of scope to manage individual resources.

If we were to implement management of s3 bucket policies, where should we represent these policies in the filesystem?

Option 1: Prefix using the service name iam or s3 - would require existing filesystem to move around slightly e.g.

{account-id}/iam/{user,group,role,policy}/{name}
{account-id}/s3/{bucket-name}

Option 2: Don't move anything e.g.

{account-id}/{user,group,role,policy,s3}/{name}

Option 3: Follow the ARN format ordering e.g.

iam/{account-id}/{user,group,role,policy}/{name}
s3/{account-id}/{bucket-name}

I'm leaning towards Option 2.

References:

• http://docs.aws.amazon.com/AmazonS3/latest/dev/access-policy-alternatives-guidelines.html
• http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html
• http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html

[SomeoneWeird]

I would be totally down with this, it was one of the first things I noticed it didn't do, as we're extensively using S3 policies at work. Personally I like option 2 the best, as it doesn't require changing anything.

[joho]

I'll defer to you and @pda @mtibben

[simpsora]

Managing bucket policies would be ace. I prefer options 1 or 3 (for consistency's sake), but would be happy with option 2.

[pda]

👍 for option 2 because it's backwards compatible and keeps things simple. I can't imagine s3 becoming an IAM resource type alongside user,group,role,policy so I don't think it'll bite us. I prefer the account ID at the top of the hierarchy, rather than {iam,s3}.

[lox]

Yup, my vote would be for option 2.

[mtibben]

Fixed in #16