In Amazon Web Services (AWS), it’s common for organizations to have multiple AWS accounts to manage their resources and maintain security and compliance. In these cases, it’s necessary to have a way to access resources across accounts, and that’s where the AWS Assume Role feature comes in.
What is Assume Role and why use it for Cross-Account Deployment
Assume Role enables users in one AWS account to access resources in another AWS account. This feature allows organizations to centralize management, access shared services, secure data access, maintain compliance, and allocate costs effectively.
Step-by-Step Guide to Deploying AWS Resources with Assume Role
This article will show you how to deploy AWS resources cross account using Assume Role.
Step 1: Create an IAM Role in the Trusted Account (Account B)
The first step is to create an IAM role in the trusted account (i.e., the account that contains the resources you want to access). The role should have permissions to access the required resources.
Here’s an example of how to create the role:
- Log in to the AWS Management Console of the trusted account.
- Navigate to the IAM service.
- Click on “Roles” and then “Create role.”
- Choose “Another AWS account” as the type of trusted entity.
- Enter the AWS account ID of the account that will be using the role.
- Click on “Next: Permissions.”
- Attach a policy that grants the necessary permissions to access the resources in the trusted account (e.g. AdministratorAccess).
You can update the Trust Policy for the IAM Role by adding “sts:ExternalId,” which refers to a unique identifier used in the AWS Security Token Service (STS).
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT_A_ID:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345678TESTID"
}
}
}
]
}
Instead of using the AdministratorAccess policy, you can use the following custom policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ExamplePolicy",
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"cloudformation:*",
"sqs:*",
"events:*"
],
"Resource": "*"
}
]
}
Step 2: Create an IAM User or Group in the Trusting Account (Account A)
The next step is to create an IAM user or group in the trusting account (i.e., the account that will be using the role). The IAM user or group should have the necessary permissions to access the resources in the trusted account.
Here’s an example of how to create an IAM user:
- Log in to the AWS Management Console of the trusting account.
- Navigate to the IAM service.
- Click on “Users” and then “Add user.”
- Enter a name for the IAM user.
- Select “Programmatic access” as the access type.
- Click on “Next: Permissions.”
- Assign the IAM user a policy that allows them to assume the role in the trusted account.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"iam:PassRole",
"iam:ListRoles"
],
"Resource": "arn:aws:iam::ACCOUNT_B_ID:role/<role-name>"
}
]
}
Step 3: Assume the Role and Access the Resources
The final step is to assume the role and access the resources in the trusted account.
Download the AWS IAM User Credentials from Account A and configure them on the device where you want to execute the assume role command.
Here’s an example of how to assume the role in Account B with an external ID using the AWS CLI:
aws sts assume-role --role-arn "arn:aws:iam::ACCOUNT_B_ID:role/<role-name>" --role-session-name AWSCLI-Session --external-id 12345678TESTID
Configure access key ID, secret access key, and session token as environment variables.
export AWS_ACCESS_KEY_ID=RoleAccessKeyID
export AWS_SECRET_ACCESS_KEY=RoleSecretKey
export AWS_SESSION_TOKEN=RoleSessionToken
I made a simple Bash Script file to automate the assume-role command and deployment to AWS resources.
#!/bin/sh
OUT=$(aws sts assume-role --role-arn "arn:aws:iam::231009317852:role/CrossAccountAccessRole" --role-session-name AWSCLI-Session --external-id 12345678TESTID);\
export AWS_ACCESS_KEY_ID=$(echo $OUT | jq -r '.Credentials''.AccessKeyId');\
export AWS_SECRET_ACCESS_KEY=$(echo $OUT | jq -r '.Credentials''.SecretAccessKey');\
export AWS_SESSION_TOKEN=$(echo $OUT | jq -r '.Credentials''.SessionToken');
# deploy to AWS cloud using serverless framework
npm run deploy
This example assumes that you have Node.js and npm project installed on your local machine. The npm run deploy
command deploys the project to the AWS Cloud.
# package.json file
{
"name": "cross-account-sls",
"version": "1.0.0",
"description": "Infrastructure as code (IaC) for cross account among microservices",
"devDependencies": {
"serverless": "^3.23.0",
"serverless-python-requirements": "^6.0.0"
},
"scripts": {
"deploy": "sls deploy --stage develop --force --verbose"
}
}
Best Practices for Secure Cross-Account Deployment with Assume Role
- Use MFA for the root account: Enable multi-factor authentication (MFA) for the root account to add an extra layer of security.
- Create IAM users for each person: Instead of using the root account, create IAM users for each person who needs access to AWS resources.
- Create separate AWS accounts: Create separate AWS accounts for production and non-production workloads to ensure isolation.
- Grant minimum required permissions: When using Assume Role, grant only the minimum permissions required to perform the task. This can be achieved by using IAM policies with least privilege principles.
- Use Role Chaining: If a user needs to access multiple AWS accounts, use role chaining to minimize the number of times a user needs to switch roles.
- Enable AWS CloudTrail: Enable AWS CloudTrail in each AWS account to track the use of the Assume Role feature and monitor any unauthorized access.
- Monitor and rotate credentials: Regularly monitor the use of AWS credentials and rotate them regularly to reduce the risk of unauthorized access.
- Use AWS Organizations: Use AWS Organizations to centrally manage and consolidate multiple AWS accounts, including the use of cross-account access.
By following these best practices, you can ensure secure cross-account deployment and minimize the risk of unauthorized access to your AWS resources.
I hope this blog has helped you. Feel free to leave a comment in the section below for further recommendations
Tags: assume role, aws, best-practice, cross-account deployment, deployment, step-by-step