Restricting a Role's S3 Write Privileges - amazon-web-services

Question

I would like to restrict my role from writing to unauthorized buckets in different accounts. For example, I will have role A in account A. S3 bucket B is created in account B and has a bucket policy allowing role A to write into it. I need a policy on role A/account A to prevent role A from being able to write into bucket B.
Is this possible?

Answer 1

Probably the easiest (from an IAM Policy perspective!) way to achieve what you are looking for, while minimizing the risk of overlooking something and introducing a potential security problem, is to use Access Points.
You can create Access Points and associate them with your buckets. Then, instead of trying to interact with the bucket directly, you interact with the Access Point.
The reason this can help you is that there's an IAM Policy Condition Key available to test the Account ID that owns an Access Point. What you need to do, then, is simply add a statement to your IAM Role's Policy that will "Effect": "Deny" all S3 actions, on all resources, when the request matches a condition that tests "StringNotEquals": { "s3:DataAccessPointAccount": "YOUR_ACCT_NUMBER" }.
Note that you'll not be able to access any S3 resources without going through an Access Point. So this will increase your initial setup complexity (and the complexity of creating new buckets, since now you'll also need to create and associate an access point). It will also become more complex to interact with S3, since you'll now always need to go through the Access Point.
Those are trade-offs you'll need to accept if you want to implement a solution like this. But it'll achieve your goal: it'll be impossible for this IAM Role to access S3 buckets outside of your account.
Here's what the Policy would look like (tailor it to your specific needs):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "denyWithoutAccessPoint",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"s3:DataAccessPointAccount": "YOUR_AWS_ACCT_ID"
}
}
}
]
}
Keep in mind that you'll also need to Allow any operations that you need.
If this trade-off (more complexity interacting with S3 for a completely straightforward IAM Policy) doesn't work for you, you'll need something different.
Keep in mind that there's always a trade-off.
Alternative 1
One alternative possibility is what #Marcin described: explicitly deny access to these buckets in the other accounts.
However, the trade-off here is that you'll never know what are all the S3 Buckets, owned by other AWS accounts, that granted access to your IAM Role.
So you can only deny access to the buckets you know about.
In a threat model in which the attacker wants to exfiltrate data from your account, they could create a new bucket that you don't know about, grant access to the IAM Role through a Bucket Policy on that new bucket, and then somehow make to role write into that newly created bucket.
Benefit: no changes to how your applications use S3.
Disadvantage: possible attack scenario since you can't know the entire list of buckets from other accounts that allow access to your role (i.e., you'd be blocking access "reactively", that is, only after something bad could have already happened).
Alternative 2
Another alternative is for you to instead create an IAM Policy that explicitly denies access to all buckets NOT enumerated in the policy.
To implement this "negated list", you use NotResource, rather than the more common Resource policy element.
Here's what the policy would look like:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "denyWithoutAccessPoint",
"Effect": "Deny",
"Action": "s3:*",
"NotResource": [
"arn:aws:s3:::my-bucket-1",
"arn:aws:s3:::my-bucket-1/*",
"arn:aws:s3:::my-bucket-2",
"arn:aws:s3:::my-bucket-2/*"
]
}
]
}
Again, like in the other sample policy in this answer, remember that you'll still need to explicitly allow actions.
Benefit: you don't need to change the way you interact with S3, and you don't have to know the names of all buckets in other accounts that allow access to your IAM Role.
Disadvantage: you need to maintain this growing list of buckets. Also, keep in mind that there's a maximum policy size that you may eventually hit, making this solution limited in scale (although it can grow quite a lot).

Answer 2

By default buckets are private. But if you already have a bucket policy allowing a role in Account A to write to it and don't want to check the policy, you could add
an explicit deny to the role.
The deny would prohibit s3::PutObject on the bucket and its objects. This works because:
an explicit deny in any of these policies overrides the allow.
En example of such a policy which could be added to the role in Account A is following:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "deny-puts-to-bucket-in-acc-b",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::<bucket-from-account-B>/*",
]
}
]
}
This only denies PutObject. You may consider other actions as well such as PutObjectAcl or actions on the bucket itself and many more.
Nevertheless, the above policy should be a good start to tailor it to your specific requirements.