Before we get started, there are (too) many ways to restrict S3 bucket access from any internal/external accesses such as Access Point, ACL, Bucket Policy, IAM, Pre-signed URL, ... and so forth. In this post, I am going to be focusing on explaining the Access Point, what it is and how to use it.
1. What is Access Point?
According to the official document of AWS, Access Point is ...
"As an application set grows, the bucket policy becomes more complex, time consuming to manage, and needs to be audited to make sure that changes donβt have an unexpected impact on another application."(Amazon Web Services)
"Amazon S3 Access Points, a feature of S3, simplify data access for any AWS service or customer application that stores data in S3. With S3 Access Points, customers can create unique access control policies for each access point to easily control access to shared datasets."(Amazon Web Services)
Access Point is useful when you want to organized many user level access. If you mostly deal with bucket level access, and constraints are pretty less, then sticking to Bucket Policy would still be the best option. The choice is completely up to developers. I personally think small projects would not need to manage their S3 Accessibility by using Access Point.
But still, for future big projects knowing how to work with Access Point is very important in case your Bucket Policy gets super big, since Access Point Policy allows you to break down the policies and organize them.
2. How to use Access Point then?
Workflow is simple. First, give IAM users restricted S3 permissions using special tags such as s3:DataAccessPointArn
, s3:DataAccessPointAccount
, and s3:AccessPointNetworkOrigin
Second, configure the Bucket Policy and Access Point Policy to grant users S3 permissions only through Access Point.
3. Simple Experiment with IAM Policy
Experiment workflow
- Give an IAM user a restricted s3 permission.
- Create an Access Point for a bucket and make it accessible by the IAM user.
Expected behaviors
When the IAM user access the bucket directly and perform
s3:GetObject
, the user will getAccess Denied
error instead of an object.When the IAM user access the bucket through created Access Point and perform
s3:GetObject
, the user will get the object.
Create an IAM user with full s3 permission except s3:GetObject
and s3:PutObject
. Deny those actions if requests are NOT coming from the Access Point demo-access-point
. I used s3:DataAccessPointArn
property.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::*",
"arn:aws:s3:*:<ACCOUNT_ID>:accesspoint/demo-access-point",
"arn:aws:s3:*:<ACCOUNT_ID>:accesspoint/demo-access-point/*"
]
},
{
"Effect": "Deny",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "*",
"Condition": {
"StringNotLike": {
"s3:DataAccessPointArn": "arn:aws:s3:*:<ACCOUNT_ID>:accesspoint/*"
}
}
}
]
}
We haven't created the Access Point so let's go to create one.
Create a bucket with unique name. I used demo-for-access-point-tutorial
.
Upload any files and create an Access Point named demo-access-point
. For the Access Point Policy, allow the IAM user to perform s3:GetObject
and s3:PutObject
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GetObject",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:user/DemoAccessPointUser"
},
"Action": ["s3:GetObject","s3:PutObject"],
"Resource": "arn:aws:s3:<REGION><ACCOUNT_ID>:accesspoint/demo-access-point/object/*"
}
]
}
Congrats! You just restricted the user's s3 GetObject and PutObject permission using Access Point Policy and IAM Policy!
Let's check out the outputs
Case #1: Trying to access an object through the bucket
Case #2: Trying to access an object through the Access Point
4. Conclusion
Access Point can be useful when there are many IAM users and groups that we need to restrict the access to specific buckets because the bucket's Bucket Policy can be too large and end up being hard to manage.
Top comments (0)