|

Scenario and goal:

For various reasons, some customers may wish to segregate their environments using separate AWS accounts rather than VPCs.

Account A contains management/deployment components including an Ansible control server. The desired goal is to run Ansible playbooks on the control server/instance in Account A in order to deploy components (EC2, ELB etc) in to Account B.

 

Cross-account deployment

Account A ID:111111111111 | Account B ID:222222222222

Requirements:

IAM role in Account B with two policies:

  • Policy with permissions to AWS services
    • We’ll call the role crossacountdeploy and the attached policy, adminawsservices
  • Trust policy to allow the Account A, the trusted account, to assume the crossaccountdeploy IAM role

IAM role in Account A with a single policy:

  • Policy with a single permission to assume the crossaccountdeploy role in Account B
    • We’ll call the role deploytoaccountb and the attached policy, assumeaccountb

Account B (‘Trusting’ account)

The IAM policy adminawsservices (attached to IAM role crossaccountdeploy)

I have limited admin. rights to the specific AWS services that the Ansible control server will require access to. To understand exactly which services you want to include here, you may start with a fully permissive policy and then use the Access Advisor tool to see what services your deployments actually interact with.

The Trust Relationship Policy (defined within IAM role crossaccountdeploy)

You’ll note that I’ve added a condition to the below trust policy. Without this policy, user accounts with administrator rights in account A will be allowed to use the console to switch roles. Here, the condition restricts the assuming of the crossaccountdeploy role to a specific instance-id (e.g. Ansible control server). It would have been ideal to reference Account A’s deploytoaccountb role that the instance assumes instead of the actual instance-id. This would reduce the manual policy changes required if the instance dies or is re-provisioned through auto-scaling/auto-healing.  This is currently not an option as the “AWS Security Token Service has no service-specific context keys that can be used in an IAM policy”

Account A (‘Trusted’ account)

The IAM policy assumeaccountb (attached to IAM role deploytoaccountb)

 

Testing

We will log in via ssh to our instance in Account B and use the AWS cli tools to switch roles and then run a describe/create command in Account B. See Switching to an IAM Role (AWS Command Line Interface)

NB: If you’re using the Amazon Linux AMI, the AWS cli will already be installed. If you’re copying my script below, you’ll also need jq, which is like sed for json data. On RedHat/CentOS based distros: yum install jq

Switch roles in cli

If all goes well above, you’ll receive no error messages and you’ll be ready to test.

Describe Account B resources

Running the below command should give you json output describing Account B VPCs

Create EC2 instance in Account B

Prerequisites: you’ll need to have created a security group, ssh keypair etc. Replace the eight 9s below with your account-specific references.

 

References:

 

Related Post