Setting up Cross Account Communications in CodePipeline

A large organization would like to maintain separate AWS accounts for their environments, like development, testing, and production, to provide a high level of security and resource isolation. Before we look at the AWS recommendations, let’s discuss the benefits of this strategy.

Importance of multi-account strategy

Let’s explore the value proposition of maintaining multiple accounts in a continuous delivery pipeline:

• Administrative isolation: The first and foremost is the administrative isolation of individual resources. By maintaining separate accounts, we can maintain different levels of access to resources based on the development lifecycle or business unit. For example, we don’t want our operations teams to have write access to the developer account, and we don’t want our finance team to have write access to our test environment.

• Visibility boundary: Accounts provide a visibility boundary by restricting users and groups outside the account. Unless an administrator explicitly grants them access, the workloads are entirely invisible.

• Minimizes the blast radius: Maintaining separate accounts minimizes the blast radius. Imagine one of our accounts is hacked. By maintaining individual accounts, the impact is confined and won’t adversely impact other related accounts.

• Effective AWS service control with limits and restrictions: Imagine a scenario where we don’t want our development team to spin more than one EC2 instance. With a dedicated account, we can set AWS service limits and impose restrictions on an account without causing impacts on other environments.

• Access and visibility control: For strict auditing purposes, we must isolate the production data from being accessed by the development or operations team. We can control access and visibility to selected groups or individuals by maintaining dedicated accounts.

Cross-account communication architecture

The diagram below provides the high-level architecture of setting up multiple accounts to achieve isolation and security. An important recommendation from AWS is to dedicate a separate account for maintaining the tools of the release pipeline.

• We'll have our centralized repository, the build software, and an S3 bucket to store all the artifacts in this account.

• Typically, the operations team maintains this account, and they set up the release pipeline based on the project requirements, and developers will not have write access to this account.

• The administrator must restrict access to update the release pipeline to a few individuals.

• The next step is to create separate accounts for test and production environments. Since we cannot use the AWS Console to set up this communication, we must rely on AWS CloudFormation templates. The CloudFormation template is a simple JSON or YAML file, where we declare all the resources that must be provisioned in an environment. The CloudFormation service accepts this template file as input and provisions infrastructure automatically. This process is also referred to as IaC (infrastructure as code).

• Once a developer commits a code change to the repository, CodePipeline will check out the code and initiate a build using AWS CodeBuild. CodeBuild will create the deployment artifacts, including AWS CloudFormation templates, and upload them to the S3 bucket.

• AWS CodePipeline must be provided with the cross-account role to execute this CloudFormation template in the test and production accounts to provision the instances and deploy applications.

• We have now achieved the highest isolation and security level by maintaining dedicated accounts.

• By maintaining a centralized account for all the services participating in the release process, we eliminate the need to duplicate the pipeline across environments. Referring to the diagram below, we can see that the tools environment is the centralized account where the application code is built, merged, reviewed, and unit tested. They are then deployed to the test environment, a dedicated account separate from the production environment.