Nowadays, it is an ideal practice to keep different AWS accounts for IAM users and a different account for running production infrastructure. Also, Terraform is used to manage and provision cloud infrastructure. To create infrastructure in one account while users reside in another, the user needs to assume the role of that account. To provision resources using Terraform, which executes on an EC2 instance in AWS account where users reside, we need to assume role by saving credentials of resources account on the EC2 instance. There is a more secure solution to it.
Problem: To have Terraform running on EC2 in one AWS account (Account A) and create resources in another AWS account (Account B) securely.
Account A: Here we host the EC2 instance that runs our Terraform scripts. We are assuming that you have an EC2 instance created with Terraform already installed.
Account B: This is the account where we want Terraform from Account A to create resources, such as an S3 bucket. It could very well be any other resource(s) that can be created using Terraform templates.
Solution steps:
Step 1. In Account B, create a role (s3_terraform) that trusts Account A. You will need to enter the account number(ID) of Account A when creating the role. This will attach a trust policy to the s3_terraform role as given below. Make a note of the role ARN. You will need this ARN in step 4.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Principal" : {
"AWS" : "arn:aws:iam::<ACCOUNT A ID here>:role/ec2_role"
},
"Action" : "sts:AssumeRole",
"Condition" : {}
}
]
}
Step 2. To this s3_terraform role, attach policies that allow S3 bucket creation. For simplicity, you can attach S3FullAccess managed AWS policy.
Step 3. In Account A, create a role (ec2_role). Attach the following policy that allows ec2_role to assume the s3_terraform role which is in Account B. You can also use visual editor to create this policy. To do that, search for STS service and select "sts:AssumeRole" action when creating this policy. You will need to specify the ARN of s3_terraform role in the policy that you will attach to this role. Use the ARN that you noted in step 1. You can either attach this role to an already created EC2 instance or specify this role while creating a new EC2 instance.
{
"Version" : "2012-10-17",
"Statement" : [
{
"Sid" : "VisualEditor0",
"Effect" : "Allow",
"Action" : "sts:AssumeRole",
"Resource" : "arn:aws:iam::<ACCOUNT B ID here>:role/s3_terraform"
}
]
}
Step 4. SSH into the EC2 instance that already has Terraform installed. The provider.tf file should contain the following. It should have the ARN of role which needs to be assumed. Use the ARN that you noted in step 1.
provider "aws" {
assume_role {
role_arn = "arn:aws:iam::<ACCOUNT B ID here>:role/s3_terraform"
}
}
Step 5. In this example we are creating an S3 bucket via terraform. The S3.tf file should contain below code to create the new bucket resource.
resource "aws_s3_bucket" "b" {
bucket = "my-bucket"
acl = "private"
tags = {
Name = "My bucket"
Environment = "Dev"
}
}
You can now run "terraform init" followed by plan/deploy to see your roles in action. We have effectively achieved “Role Cascading” in this.
Benefits: We do not need to store AWS credentials on EC2 instance to assume a role as they are acquired by Terraform on-the-fly through the EC2 metadata API. Any solution involving the creation of an access key then introduces the complexity of managing that secret.
You can specify the AWS_METADATA_URL environment variable in the EC2, but it is not necessary. Terraform defaults to http://169.254.169.254:80/ latest as per their documentation.
While this example is about Terraform, it could’ve been any other application that requires to assume a role in another account to access AWS services and resources there. This can be turned into a generic use case.
