In a modern enterprise architecture, cloud resources are typically managed by individual teams and organized across multiple AWS accounts. However, certain resources are deliberately designated as shared components, such as a centralized API gateway integrated with diverse platforms, or a unified storage solution accessed by various applications. Therefore, it is imperative to carefully design a secure approach to granting such access.
Scenario
Consider that during execution, a Lambda function in one AWS account (Account A with account ID 111111111111) needs to access a S3 bucket located in another AWS account (Account B with account ID 222222222222).
Note: While the example here focuses on accessing a S3 bucket, the concepts discussed later can be applied to all AWS services.
To understand the concept of cross-account access, it is essential to first examine how access control operates within a single AWS account. An IAM user is an entity that interacts with different AWS resources. Permissions can be assigned individually to each user, ensuring the restriction to only the operations or resources necessary for completing specific tasks.
At this stage, one might naturally contemplate setting up an IAM user in Account B as a service account to enable the Lambda function to programmatically access the S3 bucket using its security credentials. However, while technically feasible, this approach relies on long-term access keys, which poses an account security risk and contravenes the security best practices.
In light of this, IAM roles eliminate standard long-term credentials and provide temporary security credentials when being used. An IAM role is similar to an IAM user in that it is also governed by permission policies that define the authorized actions to perform on AWS. Instead of being exclusively associated with one user, a role is intended to be assumable by anyone who needs it.
Building upon the prior architectural blueprint, slight adjustments can be made to incorporate the utilization of an IAM role. Instead of accessing the S3 bucket as an IAM user in Account B, the Lambda function now assumes a role in Account B and accesses the S3 bucket during the role session.
Creating IAM Role in the Destination Account
The IAM role in the destination account should include the permissions required for executing operations on designated resources. Determining the precise permissions can be approached as though the resources are being accessed locally within the same account. There is no need to account for cross-account usage at the moment. In the mentioned scenario, AmazonS3ReadOnlyAccess serves as an appropriate initial permission policy. It may be advisable to further restrict the resources to one or a few specific buckets of interest. The following shows an example permission policy that allows all read operations on a bucket in Account B.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*",
"s3:Describe*",
"s3-object-lambda:Get*",
"s3-object-lambda:List*"
],
"Resource": "*"
}
]
}
Note: The permissions can be tested by utilizing an IAM user within the same account to assume the role.
Once the necessary permissions are properly configured, the trust policy can be configured to allow entities from other AWS accounts to assume this role. The following trust policy allows any entities in Account A to assume this role in Account B.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "111111111111"
}
}
]
}
Configuring Permissions in the Source Account
The destination account now permits entities in the source account to assume a role within it. However, it is still necessary to grant an AssumeRole permission to these entities in the source account so that they can successfully initiate an AssumeRole request. In the context of the above scenario, each Lambda function is assigned an underlying execution role, which provides the necessary permissions for the function to access AWS services and resources. Hence, the following policy should be appended into the Lambda execution role for it to assume the role in Account B.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*"
}
]
}
Testing for Cross-Account Access
With all configurations completed, the Lambda function code in Account A can now be updated as specified, followed by testing to verify its access to the S3 bucket in Account B.
import boto3
def lambda_handler(event, context):
# Configure assume role session
assume_role = boto3.client('sts').assume_role(
RoleArn='arn:aws:iam::222222222222:role/s3-role',
RoleSessionName=context.function_name
)
session = boto3.session.Session(
aws_access_key_id=assume_role['Credentials']['AccessKeyId'],
aws_secret_access_key=assume_role['Credentials']['SecretAccessKey'],
aws_session_token=assume_role['Credentials']['SessionToken']
)
# List all objects in a S3 bucket in another account
objects = session.client('s3').list_objects(
Bucket='bucket-in-222222222222',
)['Contents']
print(objects)
As indicated in the function logs, the objects variable contains all objects within the bucket bucket-in-222222222222, signifying a successful configuration for cross-account access.
Restricting IAM Policies (Recommended)
As observed, the permissions are either applied universally to all resources or granted to all principals within the AWS account, resulting in a scope that significantly exceeds the actual requirements. In alignment with the principle of least privilege, identities should only be permitted to perform the smallest set of actions necessary to fulfill a specific task.
The following outlines some suggested enhancements based on the example scenario, assuming that the Lambda function is the only entity in Account A requiring access to the bucket bucket-in-222222222222 in Account B.
-
Restrict the scope of the S3 permissions assigned to the IAM role in Account B to the bucket
bucket-in-222222222222.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*", "s3:Describe*", "s3-object-lambda:Get*", "s3-object-lambda:List*" ], "Resource": "arn:aws:s3:::bucket-in-222222222222" } ] } -
Restrict the principal scope of the trust policy on the IAM role in Account B to the Lambda execution role in Account A.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": { "AWS": "arn:aws:iam::111111111111:role/service-role/lambda-execution-role" } } ] } -
Restrict the scope of the
AssumeRolepermission assigned to the Lambda execution role in Account A to the IAM role in Account B.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/s3-role" } ] }
Depending on your specific use case, you may choose to adopt all or only some of the suggested changes.
This article outlines one method for enabling cross-account access through role assumption. Administrators of the destination account (i.e. Account B) are fully responsible for determining the precise permissions required for a task and configuring them in a role. In contrast, administrators of the source account (Account A) only need to assign the AssumeRole permission to the IAM users or groups involved in cross-account operations. This approach enhances architectural agility, as any changes in permission requirements can be addressed by simply updating the relevant policies in the destination account.
Alternative approaches, such as using resource-based policies, can also address the same issue. It is recommended to evaluate and compare these methods to determine which best aligns with your specific environment and requirements.
References
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
- https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html
- https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html
Top comments (0)