Setting up cross-account Amazon S3 access with S3 Access Points

Customers have told us that they are often required to grant external users or users from other accounts within their organization access to certain Amazon S3 buckets. At times, this access may need to be more granular, such as granting access to only certain prefixes. Historically, if you needed to grant permission to the bucket to another account, you had to edit the S3 bucket policy that controlled that bucket’s permissions. However, customers prefer to put restrictive rules around editing bucket policies, to ensure that access isn’t being granted more broadly than what they wanted, as they have certain guardrails and compliance requirements. This could be to prevent users from creating public buckets, either purposefully or inadvertently. Generally, when these customers create a new S3 bucket, they have an automatic way to apply these bucket policies for compliance. After the bucket creation, they can deny all users including the S3 bucket creators from editing the bucket policies in place, for security reasons.

In this blog, I cover enabling S3 Access Points for cross-account access (access between accounts) without having to edit bucket policies for access. In this solution, you create a bucket policy only once, with the policy enabling the use of Access Points. After this, the Access Point policy grants access to all users based on the terms of the policy, preventing you from having to edit S3 bucket policies. This solution enables you to enforce granular access to your Amazon S3 objects with flexible cross-account access without having to edit bucket policies. This solution assumes three separate parties:

• The Data Owner who uploads items that another party will view into an S3 bucket.
• The Data Consumer who requires access to the items in the S3 Bucket.
• The Security Administrator who creates the policies required (S3 Bucket policy and Access Point policy) to setup the process. In this blog, one of the AWS CloudFormation templates does the Security Administrator’s job.

Amazon S3 Access Points

S3 Access Points, a feature of Amazon S3, simplifies managing data access at scale for applications such as data lakes, using shared datasets on S3. Access Points are unique hostnames that customers create to enforce distinct permissions and network controls for any request made through them. Access Points use policies to grant access to Amazon S3. Unlike bucket policies, they only support specific S3 actions for security purposes. You can find all S3 actions that S3 Access Points enable here.

S3 Access Points can be accessible via the internet or restricted to an Amazon VPC, via VPC endpoints and AWS PrivateLink. They are very powerful and you can use them Region-wide to grant and limit access. This blog demonstrates how you can enable cross-account access into S3 buckets with S3 Access Points. When requesting S3 Access Points from an Amazon VPC, it is available via the AWS CLI, AWS SDK, or S3 REST API. Currently, you cannot access S3 Access Points requested from an Amazon VPC via the console. On the other hand, you can access internet S3 Access Points via the console. To demonstrate certain parts of the S3 Access Points console, I use S3 Access Points via the internet in this blog. You can also create Access Points with a specific VPC Network Origin. In that case, you would not have been able to use the AWS Management Console.

When used together, S3 bucket policies and S3 Access Point policies result in an intersection of the permissions granted by the bucket policy and the Access Point policy. If an S3 bucket policy only allows s3:Put, and an S3 Access Point policy allows s3:Put and s3:Get, the user using that S3 Access Point is only be able to perform s3:Put actions. This means for security purposes you can delegate access control to an S3 Access Point via its bucket policy and use the S3 Access Point policy to grant that access. You write an S3 Access Point policy like an IAM policy, and the following example uses the S3 action GetObject. This action enables the role s3user to get objects from said bucket via the S3 Access Point called operations.

{  
"Version": "2012-10-17", 
"Statement" : [
{
"Effect": "Allow",
"Principal" : {
 	"AWS": "arn:aws:iam::ACCOUNT_ID:role/s3user" 
       },
"Action" : "s3:GetObject",
"Resource" : "arn:aws:s3:eu-west-2:ACCOUNT_ID:accesspoint/operations/object/*"  
}
]
}

Prerequisites

I cover an example of an audit team. Assuming a user in an audit team requires access to a folder in an S3 bucket in another account, they can create an Access Point with a policy that specifically grants this access. Now they can have their default S3 bucket policy as usual, but including a one-time policy granting Access Points in that account. This saves them from having to worry about needing to edit the bucket policy each time access is required.

To demonstrate cross-account access using S3 Access Points, this solution assumes that two accounts exist (Account A and Account B), with an S3 bucket in one account (Account A). These accounts can be part of an organization or otherwise. If you would like to set up an organization structure, see this tutorial on creating and configuring and organization.

Solution overview

You create an S3 Access Point (S3 Access Point policy) alongside an S3 bucket policy to grant adequate access to the user (audit administrator) requiring cross-account access. For this solution, you deploy two AWS CloudFormation templates (provided in the deployment section) into Account A and Account B. The following architecture diagram shows an overview of the solution:

Account A (The Data Owner)

This is the account you create the Amazon S3 Access Point in. The user in Account B requires cross-account access to this account to use the Access Point.

Services deployed in Account A:

• An Amazon S3 bucket with a bucket policy to grant access to the S3 Access Point.
• A cross-account role to enable a user in Account B to assume access.
• An S3 Access Point in the S3 bucket with its own policy to grant s3:GetObject access to the user that assumes the cross-account role.

Account B (The Data Consumer)

This is the account that is using the S3 Access Point and will use cross-account access to Account A to use S3 Access Point.

Services deployed in Account B:

• An IAM user with console access and policy to assume the cross-account role created in Account A.

Deploying the solution

In this section, you deploy the AWS CloudFormation templates into both accounts A and B. This creates the Amazon S3 bucket and Policy, Amazon S3 Access Point, and cross-account IAM Role.

1. In Account A, deploy this template in AWS CloudFormation, enter in the parameters shown in the following screenshot, and give the stack a name. Note that you can change the Parameters depending on your needs or preferences. Also, pRoleName should be the same in both templates you deploy, and pAuditAccountID should be the account ID of Account B.

2. Follow the instructions on the screen and deploy the template.

3. Log in to Account B, deploy the second template in AWS CloudFormation, enter in Parameters as shown in the following screenshot, and give the stack a name. Enter a password and note this down. Note that you can change the Parameters depending on your needs or preferences. As noted in the first step, the parameter pRoleName should be the same in both templates and pAuditAccountID should be the account ID of Account A.

Trigger activities in main account

In this section, you create objects within a specific folder in the S3 bucket to give the already deployed AWS user in the audit account access to that specific folder.

1. After you have successfully deployed the correct templates into the respective accounts, log in to Account A. In AWS CloudFormation, select the deployed stack and switch to the Resources Under Logical ID, look for rS3Bucket and click on its Physical ID to open the S3 bucket.

2. Click on Create folder. Here you create a folder and upload files to enable access to the cross-account user. Name the folder “audit” (this is the same name as the parameter pFoldertoAccess), and click Save.

3. In the Access Points tab, you should be able to see the S3 Access Point created in addition to its policy.

Cross-account access

In this section, you access the Amazon S3 Access Point created via cross-account access.

1. Log into Account B and navigate to IAM. You should find the user created from the AWS CloudFormation template (pUsername entered as “auditadmin” in step 4).

2. Click on the user and open the Security Credentials tab to copy the console link. Then, open a new tab in your browser and paste the link to log in.

3. Login using the pUsername (“auditadmin”) and pPassword (both from step 4).
4. Enter the pAuditAccountID of Account A for Account and the pRoleName (“S3AccessPointRole”) for Role. The Display Name can be anything, as shown in the following screenshot: For more detailed steps on how to assume roles from the console, check out this documentation.
   
5. Go to Amazon S3 and find the bucket created – notice you cannot download objects from the bucket. Switch to the Access Points tab and select the S3 Access Point previously created (‘ops-audit’ from step 1). Click Use this Access Point as shown in the following screenshot:

*If using an S3 Access Point via a VPC, install the AWS CLI, log in to the account with credentials, and run the following command:

aws s3api get-object --key my-image.jpg --bucket arn:aws:s3:eu-west-2:123456789012:accesspoint/ExampleObject.jpg

6. Try to download the object from the audit folder again. You should be able to download the object now.

Cleaning up

Remember to clean up if incurring charges for maintaining this solution is unwanted. Complete the following two steps to do so.

1. In Account A, go to the S3 bucket and delete the ‘audit’ folder. Navigate to AWS CloudFormation and delete the stack.
2. In Account B, navigate to AWS CloudFormation and delete the stack.

Conclusion

In this post, I covered granting granular access with S3 Access Points – in the example, I granted the user from the audit team access to a specific folder in the S3 bucket. As the S3 bucket policy did not need to be changed, I avoided possible security and compliance mistakes, such as inadvertently granting public access, through modifying the Access Point policy instead. I showed how you can setup and enable cross-account access between two Access Points for a specific prefix from a specified VPC without having to edit bucket policies for access control at the bucket level.

The introduction of S3 Access Points is a complete game changer. You now do not have to worry about constantly editing bucket policies or creating mammoth bucket policies when you must grant access from various accounts. S3 Access Points are being widely adopted due to the freedom it grants without compromising on security or compliance in addition to how well it integrates with other AWS services.

In a future blog, I plan to show one of the many ways you can use S3 Access Points with other AWS services such as AWS Lambda, AWS CloudFormation, and Amazon SNS. Make sure to read then to learn how to automate the deployment and configuration of Access Points with CloudFormation. I also plan to cover how to notify an audit administrator via Amazon SNS when objects are available for them to view via the S3 Access Point, and how to take a desired action with AWS Lambda a result. If you are interested in further exploring security on Amazon S3, see here.

Thanks for reading this blog post, if you liked this or have any questions, please leave a comment in the comments section.