Cross-Account Access (same region) to S3 Buckets Encrypted with a Customer Managed KMS Key
Table of contents
No headings in the article.
Introduction
With an ever-growing emphasis on data security, businesses are leveraging Amazon Web Services (AWS) to manage and secure their data. Two key services in this endeavor are Amazon Simple Storage Service (S3) and Key Management Service (KMS).
Amazon S3 provides scalable and efficient data storage, while KMS offers easy management of cryptographic keys. Together, they form a solid foundation for secure data storage and access.
In this blog post, we'll delve into the specifics of setting up secure cross-account access to an S3 bucket encrypted with a customer managed KMS key. This setup is especially relevant for enterprises operating across multiple AWS accounts, providing a secure way to access data stored in S3 from an EC2 instance in a different AWS account.
Prerequisites
Before diving into the process, we need to ensure a few things are in place:
Two AWS Accounts: We need two separate AWS accounts - one for the source (where the S3 bucket and customer managed KMS key are hosted), and the other for the target (where the EC2 instance is located).
Amazon S3 Bucket: A configured S3 bucket in the source account with files stored in it. The bucket should be encrypted using a custom KMS key.
Custom KMS Key: A custom KMS key in the source account used for encrypting the S3 bucket.
Amazon EC2 Instance: A running EC2 instance in the target account, which will access the S3 bucket.
IAM Roles and Policies: Properly configured IAM roles and policies in both accounts to allow the necessary permissions for cross-account access.
AWS CLI: AWS CLI installed and configured on the EC2 instance for executing AWS commands.
With these prerequisites met, we can proceed to the setup for secure cross-account access.
Understanding the Concepts:
This part of the article explains key concepts that are critical to our setup:
S3 Bucket and KMS Key: Amazon S3 securely stores your files. It supports server-side encryption with AWS managed keys (SSE-S3), AWS Key Management Service (KMS) keys, or a customer-provided key. We'll use a custom KMS key for encryption.
Cross-Account Access: AWS allows resources in one account to be accessed by entities in another account. This is handled through IAM roles and resource-based policies, like S3 bucket policies and KMS key policies.
IAM Roles: IAM roles are AWS identities with permission policies allowing IAM entities to make AWS service requests. Roles can be assumed by trusted entities, including an EC2 instance.
AWS CLI: The AWS Command Line Interface (CLI) is a unified tool that lets you manage your AWS services from a terminal session on your own client, allowing direct control over AWS services.
With these concepts in mind, we can delve into the actual process of setting up cross-account access.
Setting up the Environment:
1.Account Creation: Set up two AWS accounts, Account A (source) and Account B (target).
2.S3 Bucket and KMS Key: In Account A,create a customer managed KMS key without making any changes to the defaults in the aws console during the key creation. The bucket will store your files, and the key will be used for server-side encryption.
KMS Key names accounta-cmk is shown below:
Encrypted s3 bucket named account-a-s3bucket created with using the customer managed kms key created above:
3.IAM Role: In Account B, create an IAM role with permissions to access the S3 bucket and the KMS key in Account A.
4.EC2 Instance: Launch an EC2 instance in Account B, and attach the IAM role created above to this instance.
5.AWS CLI: Log in to the EC2 using SSH or EC2 instance connect and issue the following command and you will get the error below.
aws s3 cp s3://account-a-s3bucket/amazon-s3-960x504-1.. ./ --region us-west-2
Configuring Cross-Account Access
Cross-account access can be facilitated by defining appropriate IAM roles and policies. To allow another AWS account to access your encrypted S3 bucket, you need to give it permission to the bucket and the KMS key.
The account-b destination role named account-b-role that is attached to the ec2 instance in account-b needs to have the required KMS key permissions that are in the account-a and required identity policies to access the KMS key in account-a and the s3 bucket in account-a.In addition, the account-a s3 bucket policy should allow proper access to the account-b role. The detailed requirements and configurations will be further elaborated below.
To facilitate a role attached to an EC2 instance within account-b (present in the same region) and the capability to download an object from an S3 bucket in account-a (which is in the identical region as Account-B), the subsequent steps must be implemented.
In all the policies below <> is just a placeholder and should not be there when replacing these with the actual values in your setup.
account-a s3 bucket policy:
account-a customer managed kms key policy
account-b role identity policy
Testing and Validation
Upon the successful completion of all the necessary steps, executing the command again in account-b ec2 to download the object from account-a s3 bucket will yield the following outcomes:
Best Practices and Security Considerations
Security is a critical aspect of managing AWS resources. When dealing with cross-account access and KMS keys, several best practices should be followed.
Adhere to the principle of least privilege: Only grant the necessary permissions to the other account.
Regularly rotate KMS keys and review IAM roles and policies to keep your setup secure.
Make sure to enable AWS CloudTrail for your account to keep track of all actions performed in your S3 bucket and KMS key.
Conclusion
In this post, we have seen how to configure cross-account access to S3 buckets encrypted with a customer-managed KMS key and where the s3 bucket and ec2 instance with an attached instance role belong to the same region. This setup allows for secure data storage and flexible access in multi-account AWS environments.
While AWS provides the tools to configure such a setup, it's crucial to manage these tools properly, keeping security best practices in mind.