Skip to main content

Cross Account Provisioning in AWS

Stack Automation supports multiple options for provisioning resources across multiple AWS accounts.

Here are two common approaches

Option A: Stack Automation Management Server in each account​

Requirements and Setup​

  • Each Stack Automation Management Server is sitting in a different AWS account.
  • Each Management Server is deployed in a different EKS cluster.
  • OIDC is enabled on the clusters, and they each have a valid default service account with an IAM role annotation.

Benefits and Usage​

  • Changing the Management Server on a grain (via an agent type Blueprint input with/without allowed values restriction) will change the AWS account that the grain contents will be deployed on.
  • Management Server name can also be an Account/Space parameter, which will allow switching target accounts on all blueprints/grains that reference it at once.

Architectural Diagram​

Option A Diagram: Cross Accounts provisioning with Stack Automation Management Server in each account Option A Architectural Diagram

Option B: Single Stack Automation Management Server in the Master Account​

Requirements and Setup​

  • Stack Automation Management Server is configured with a valid default service account that authenticates into an IAM role via OIDC (known as Master account role).
  • Each target AWS account has an IAM role with an identical name, with a trust policy set up to allow the Master account role to assume it (known as Target account role).
  • These Target Account roles have the permissions necessary to perform the actions Terraform will describe on the respective account.
  • By utilizing identical names, the only difference in the IAM role ARNs is the account number.

Role Trust Policy Example

This trust policy is set on the Target account role and references the ARN of the Master account role.

{  
  "Version": "2012-10-17",  
  "Statement": [ {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/My_AWS_ROLE"
      },
      "Action": "sts:AssumeRole"
  } ]
}

Terraform HCL Example

variable "aws_account_id" {}

provider "aws" {  
  assume_role {
    role_arn     = "arn:aws:iam::${var.aws_account_id}:role/ROLE_NAME"
    session_name = "SESSION_NAME"
    external_id  = "EXTERNAL_ID"  
  }
}

Stack Automation Blueprint Example

The Blueprint provides the user with a list of accounts to choose from, with a friendly text name for each account which is split out before passing the account number to Terraform.

inputs:  
  AWS Account:
    description: "The AWS Account to use"
    default: "Dev | 123456789"
    allowed-values:
      - "Dev | 123456789"
      - "Test | 234567890"
      - "Stage | 345678901"
      - "Prod | 456789012"

grains:  
  My AWS Grain:
    kind: terraform
    spec:
      source:
        store: my-repo
        path: somefolder/somesubfolder
      agent:
        name: my-agent
      inputs:
      - aws_account_id: '{{ .inputs.["AWS Account"] | split: "|" | last | strip }}'
      outputs:
      - some_output

Benefits and Usage​

  • With this structure, multiple AWS accounts are supported without requiring multiple EKS clusters or Management Servers.
  • Changing the account is as simple as changing the blueprint input value.
  • If accounts are pre-set but need to be swappable, an account/space parameter can be used instead of a blueprint input (and this allows multiple spaces to share the same blueprint but target different accounts).

Architectural Diagram​

*Option B Diagram: Cross Accounts provisioning with a Single Stack Automation Management Server in the Master Account Option B Architectural Diagram

Summary​

Both options provide flexibility in provisioning resources across multiple AWS accounts based on your specific requirements and setup.

Option A is suitable when you have separate EKS clusters for each account, while Option B allows you to manage multiple accounts from a single Stack Automation Management Server in the master account.