Cross-Account S3 Bucket Access Setup Guide

Problem Statement

Many of our clients utilize a multi-account architecture with Tower, which distributes AWS resources across multiple accounts. A common pattern observed is the use of a dedicated AWS account for file storage (e.g., Amazon S3). This setup offers several advantages, including:

• Enhanced security.

• Improved tracking of cloud usage and costs.

• Compliance with company policies.
  
  

Tower supports communication across different AWS accounts, and we have validated this capability both with and without Fusion. For additional context, refer to the AWS documentation: Provide cross-account access to objects in Amazon S3 buckets. However, Tower manages roles in a more nuanced way. This guide borrows from Platform’s role management format to illustrate the concept.

Walkthrough

In the following example, we're creating an AWS Batch Compute Environment in Account A and allowing it access to an S3 bucket in Account B 

Step 1: Create Your Compute Environment and Ensure IAM Policies Have Access to the New Bucket

1. Follow the AWS Batch Compute Environment Guide outlined in the documentation here: AWS Batch Compute Environment Guide.

2. If using Batch Forge, update the s3-write policy file to include access to the S3 bucket created in Account B.

   • In the IAM policy JSON file example provided here: S3 Bucket Write Policy, make sure you add your bucket in Account B to the Resource section. This should be done in addition to specifying your primary Compute Environment S3 bucket in Account A.

Step 2: Configure the Bucket Policy in Account B

Update the bucket policy in Account B to grant GetObject and PutObject permissions to the IAM user or role created in Account A. The bucket policy can be defined as follows:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::<Account-B-Bucket-Name>",
            "Condition": {
                "ArnLike": {
                    "aws:PrincipalArn": "arn:aws:iam::<Account-A>:role/TowerForge*"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:PutObjectTagging",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::<Account-B-Bucket-Name>/*",
            "Condition": {
                "ArnLike": {
                    "aws:PrincipalArn": "arn:aws:iam::<Account-A>:role/TowerForge*"
                }
            }
        }
    ]
}

Notes:

• The client can use the specific TowerForge role or a wildcard (as shown above) to grant account access to the bucket.

• Additional deny permissions can be configured for fine-grained security.

• In the case of a wildcard, the role name will match the one defined in the Compute Environment.

Reference: Example of the role being set while creating credentials in Platform.

Step 3: Add the S3 Bucket to the Compute Environment in Platform

1. In the Platform, include the S3 bucket as an allowed bucket within the Compute Environment configuration.

By following this guide, you can efficiently set up cross-account access for your S3 bucket while adhering to best practices for security and account management.