Learning about S3 policies.
AWS S3 bucket access can be controlled by S3 Bucket Policies and by IAM policies. If using combinations of both, there is an AWS blog post showing how the permissions get evaluated:
- If there is an explicit deny in Bucket Policies or IAM Policies, access is denied. Even if another rule would allow it, a single deny trumps any allows that would also match.
- If there is an explicit allow in Bucket Policies or IAM Policies, and no deny, access is allowed.
- If there is no explicit rule matching the request/requested, the access is denied.
An example JSON bucket policy is given as:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": ["arn:aws:iam::111122223333:user/Alice",
"arn:aws:iam::111122223333:root"]
},
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my_bucket",
"arn:aws:s3:::my_bucket/*"]
}
]
}
Policy Elements
The elements of the policy language, as used in above example:
-
Version is the date when a version was defined:
- "2012-10-17" is practically version 2 of the policy language.
- "2008-10-17" is version 1, and the default if no version is defined.
- The newer version allows use of policy variables and likely some other minor features.
- AWS recommends to always use the latest version definition.
-
Statement is cunningly named, since (as far as I understand), there can only be one such element in the policy. But it contains "multiple statements", each defining some permission rule.
-
Effect: Deny or Allow
-
Principal: Who is effected by this statement.
-
NotPrincipal: Can be used to define who should NOT be affected by this rule. For example, apply to all but the root account by using this to exclude root.
-
Action: The set of operations (actions) that this affects. For example "s3:*" means the rule should affect (deny/allow) all S3 operations.
-
NotAction: Opposite of Action, so "s3:*" here would mean the rule applies to all actions except those related to S3.
-
Resource: The resources the rule should apply to. Here it is the given bucket and all files inside the bucket.
-
NotResource: The resources the rules should not apply to. Giving a specific bucket would mean the rule should apply to all buckets except that one. Or perhaps all resources (including S3 but anything else AWS considers a resource)..?
Principal
The Principal can be defined as single user, a wildcard, or a list of users. Examples:
List:
"Principal": {
"AWS": ["arn:aws:iam::111122223333:user/Alice",
"arn:aws:iam::111122223333:root"]
},
In above, user/Alice simply refers to an IAM user named Alice. This is the user name given in the IAM console when creating/editing the user. Root refers to the account root user.
Single user:
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
The Principal docs also refer to something with a shorter notation:
"Principal": { "AWS": "123456789012" }
I can confirm that the above style gives no errors in defining the policy, which always seems to be immediately verified by AWS. But I could not figure out what this would be used for exactly. I mean, I expected this to be a rule affecting every user for the account. Did not seem to be so for my account. I posted some question, will get back to it if I get an answer..
Example Policies
Here follows a few example policies for practical illustration. Using three different users:
- root user,
- user "bob" with S3 admin role, and
- "randomuser" with no S3 access defined.
These use an example account with ID 123456789876, and a bucket with name "policy-testing-bucket":
First misconception
I was thinking this one was needed to give Bob and the root account access to the bucket and all files inside it. Including all the S3 operations:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789876:user/bob",
"arn:aws:iam::123456789876:root"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::policy-testing-bucket",
"arn:aws:s3:::policy-testing-bucket/*"
]
}
]
}
The above seemed to work in allowing bob access. But not really.
Only allor root by bucket policy
The following policy should stop Bob from accessing the bucket and files, since by default all access should be denied, and this one does not explicitly allow Bob. And yet Bob can access all files.. More on that follows. The policy in question, that does not explicitly allow Bob:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789876:root"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::policy-testing-bucket",
"arn:aws:s3:::policy-testing-bucket/*"
]
}
]
}
Denying Bob
Since the above did not stop Bob from accessing the files, how about the following to explicitly deny him:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789876:root"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::policy-testing-bucket",
"arn:aws:s3:::policy-testing-bucket/*"
]
},
{
"Effect": "Deny",
"Principal": {
"AWS": [
"arn:aws:iam::123456789876:user/bob"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::policy-testing-bucket",
"arn:aws:s3:::policy-testing-bucket/*"
]
}
]
}
The above works to stop Bob from accessing the bucket and files, as a Deny rule always trumps an Allow rule, regardless of their ordering.
IAM roles and their interplay with bucket policies
I realized the above is all because I put Bob in a "developer" group I had created, and this group has a general policy as:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
This allows anyone in this group (including Bob) to access any resources with any actions. Including resources in S3, and all actions in S3. So the explicit Allow rule higher above is not needed, Bob already has access via the his IAM group policy. This is why hist access works even if I remove him from the bucket policy. And if an explicit deny is defined, as also higher above, then the Deny trumps the IAM role Allow and blocks the access.
User with no IAM permissions
Allow listing bucket content and opening files
Since Bob was in developer group and thus has access granted via his IAM role, I also tried with RandomUser, who has no IAM role, and should be directly impacted by the S3 policy. This policy gives RandomUser access to list bucket contents and open files. but not to see bucket list, or the bucket in that list:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789876:user/arandomuser"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::policy-testing-bucket",
"arn:aws:s3:::policy-testing-bucket/*"
]
}
]
}
Block filelist view, allow file access
This stops RandomUser from seeing the filelist for the bucket but allows to open specific files in it:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789876:user/arandomuser"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::policy-testing-bucket/*"
]
}
]
}
Allow filelist, block file opening
This lets RandomUser see the bucket filelist but prevents opening files in it:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789876:user/arandomuser"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::policy-testing-bucket"
]
}
]
}
If not allowed by IAM or Bucket Policy, denied by default
If RandomUser is now allowed explicitly in bucket policies, he gets access denied:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789876:root"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::policy-testing-bucket"
]
}
]
}
Random experiments in software engineering 