Part 1 – Providing cross-account S3 access for KMS-encrypted objects

September 7, 2016 | Mike Wilkerson

At REĀN Cloud, we make heavy use of Amazon’s S3 object storage service for data of all types. With Bucket Policies, User Policies and ACLs – Amazon has provided a broad and flexible system for managing permissions and access. This allows us to grant bucket access to a third party across AWS accounts as easily as adding a statement to our S3 bucket policy. In this post, we will go over how to share encrypted objects in situations where we have updated the policy to allow access from another AWS account.

The Problem

Sometimes the data stored in our Amazon S3 buckets is sensitive, and part of securing that data involves the use of server-side encryption (SSE) of the data at rest. While Amazon provides AWS Key Management Service (KMS) to allow for easy server-side encryption using customer-managed keys, this adds a layer of complexity when it comes to granting cross-account access to those encrypted objects. A simple policy on our S3 bucket will no longer suffice because the third-party account does not have permission to use our customer keys to decrypt the objects.

For those not familiar with KMS, it is an AWS provided managed service that makes it easy for you to create and manage the keys used to encrypt your data, while using Hardware Security Modules (HSMs) to protect the security of your keys. KMS has tight integration with other AWS services, including AWS S3. (Setting server-side encryption with KMS is outside the scope of this post.) Check out the AWS blog post about securing your S3 buckets with SSE encryption via KMS.

Example Scenario

In this example, we (Account A) have an S3 bucket containing sensitive data, and we are using server-side encryption to protect the data at rest via KMS. There is a third-party, Account B, that will need access to pull a copy of our data.

The Solution

For our solution, we’ll grant read-only access to Account B so that they can pull a copy for their own use. To do so, we (Account A) will grant access to a user (User B) in Account B to copy the encrypted objects in our S3 bucket through a combination of IAM Policies, Roles, and the AssumeRole functionality.

We will need to do the following:

1. Create an IAM Policy in our account (Account A) that allows access to our S3 bucket.
2. Create an IAM Role in Account A:
   1. Attach to it our new IAM policy.
   2. Set up an External ID.
   3. Modify the Trust Relationship to allow User B to assume the role.
3. Create and attach an IAM Policy to User B, granting permission to assume the IAM Role in Account A.

As a diagram, our solution looks like the following:

Step 1: Create the IAM Policy in Account A

We need an IAM Policy in our own account, detailing the type of access to our bucket that we wish to grant:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::ACCOUNT-A-BUCKET-NAME",
                "arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"
            ]
        }
    ]
}

Step 2: Create the IAM Role in Account A

Let’s create an IAM Role in our account (Account A) that User B will eventually assume via the AssumeRole functionality.

When creating this Role, be sure to specify an External ID in addition to attaching the new Policy we just created above. An External ID serves as an additional layer of security by requiring User B to submit this information when using the AssumeRole API (more on that later). For now, think of the External ID as something similar to a password; you should not provide it to anyone other than User B. After you have created the Role, modify the Trust Relationship, and specify the ARN of User B as the trusted entity.

Stay tuned for the next post in this three part blog series. We will discuss Step 3 of the process, how to use our new Role and learn more on syncing S3 buckets across accounts. If you are interested in having our team help you in your projects, please contact us at [email protected]. Also, if you like these kind of problems and want to join our team please contact us at [email protected] or visit us at http://www.reancloud.com/company/careers/.

Read the Part 2 of this Blog Series here.