Menu
- S3 Bucket Policies
- Bucket Policy Document – Condition based on IP Address
- Cross Account S3 Bucket Configuration
- Document – Cross Account S3 Bucket Policy
- Canned ACL Bucket Policies
S3 Bucket Policies
Overview
- One limitation of IAM is that it is generally restricted to the principles like the user/group/roles within an AWS account.
- S3 buckets are often used by external entities so we need more granular permissions.
- This granularity cannot be achieved using IAM.
- S3 Bucket policies are attached directly to the S3 buckets.
Examples
- S3 is often used to host publicly accessible websites, documents, media files, etc.
- With standard controls, you can set a bucket as
- private: not accessible by anyone
- public: accessible by everyone
- With bucket policies, you can allow access from an IP or range of IPs, even though the overall policy is private.
Bucket Policy Document – Condition based on IP Address
- Use the correct ARN
- Edit the CIDR notation as required.
- Bucket > Permissions > [ Bucket Policy ]
{
"Version": "2012-10-17",
"Id": "S3PolicyId1",
"Statement": [
{
"Sid": "IPAllow",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::examplebucket/*",
"Condition": {
"IpAddress": {"aws:SourceIp": "54.240.143.0/24"}
}
}
]
}
Cross Account S3 Bucket Configuration
Overview
- It is common to use S3 buckets that require access from different accounts.
- Example:
- ORG has two AWS accounts.
- Acct A has the S3 buckets
- Acct B has EC2 instances
- These EC2 instances need to periodically backup all the data an S3 bucket in Acct A.
- How do you do this?
- ORG has two AWS accounts.
Demo
"Version": "2012-10-17",
"Statement": [
{
"Sid": "111",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AccountNumberOfAcctB:root"
},
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::examplebucket/*",
}
]
}
IMPORTANT!!
- The above policy will only grant access to the contents of the bucket (files, folders, etc.) and not to the bucket itself because of the ‘/*’.
- “Resource”: “arn:aws:s3:::examplebucket/*“
- To be able to list the contents of the bucket, you need to add just the bucket as a resource:
- “Resource”: [
- “arn:aws:s3:::examplebucket”,
- “arn:aws:s3:::examplebucket/*”,
- ]
- “Resource”: [
Document – Cross Account S3 Bucket Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "111",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::453314488441:root"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::kplabs-demo-crossover",
"arn:aws:s3:::kplabs-demo-crossover/*"
]
}
]
}
Canned ACL (Access Control List)
Understanding S3 Access Routes
- Every bucket and its objects have an ACL associated with them.
- When a request is received, AWS S3 will check against the attached ACL to either allow or block access to that specific object.
- When we create a bucket or an object, AWS S3, by default, will grant the resource owner full control over the resource.
- Resource Owner = User that uploaded the file.
- This is NOT necessarily the bucket owner
aws s3api get-object-acl --bucket bucket-name --key fileName.txt --profile accountA
... "Permission": "FULL_CONTROL" ...
- Because of the object’s ACL, the above command must be ran as the source owner of the file (person that uploaded the file)
Canned ACL
- AWS supports sets of pre-defined grants known as Canned ACLs
- Each canned ACL has a set of predefined permissions associated with them
- These canned ACL can be specified in the request using x-amz-acl header.
| ACL Name | Description |
|---|---|
| Private | Owner gets FULL_CONTROL. No one else will have access rights (Default) |
| Public-read | Owner has FULL_CONTROL. All others get Public read permissions. |
| Bucket-owener-read | Owner of the object has FULL_CONTROL. Bucket owner will get read permissions. |
| Bucket-ownder-full-control | Both the bucket owner and object owner get FULL_CONTROL over the object. |
aws s3 cp test.doc s3://bucket-name/ --acl bucket-owner-full-control --profile crossAccountUser
* This must be applied by the file uploader!!