In Part 1 you find CloudFormation templates which help you to create an AWS CodePipeline that deploys to multiple AWS Accounts. In this Part 2 we will go into some more details how these CF templates work.
Let’s first look at the 01central-prereqs.yaml template which creates:
S3 Artifact Bucket
KMS Key for encryption
CodeCommit Repo for the App
CodeBuild Project for App
Looking at the template reveals that the Dev/Test/Prod accounts get access to the KMS Key.
In the Central Account CodeBuild/CodePipeline roles will create the output artifacts, which will be encrypted with the help of the KMS Key.
Later on these artifacts will be used to deploy the application in your Dev/Test/Prod accounts, therefore the root in these accounts needs access to the KMS Key to decrypt the artifacts.
Same is needed for the artifact S3 bucket, but here the roles that will be created by the other template 02prereqs-accounts.yaml will need access to the bucket.
As you can see this policy is only added if the Condition "AddPolicies" is true, so for the first run of 01central-prereqs.yaml this S3 bucket policy will NOT be created.
Reason for this is that 02prereqs-accounts.yaml has to be deployed on the Dev/Test/Prod accounts first to create all these needed roles.
Right afterwards 01central-prereqs.yaml has to be run a second time with "AddPolicies" parameter set to true.
The template would fail to run if these roles are not present in the other accounts.
There are two roles per Account which will get access to the bucket, the CentralAcctCodePipelineCFRole and the cloudformationdeployer-role. Let’s switch to the next template 02prereqs-accounts.yaml and look at these roles.
Here you find the CentralAcctCodePipelineCFRole and as you can see, this will be the role which will be assumed by the Central Account CodePipeline to execute the CloudFormation commands.
Looking at the policy used for this role we can see that CloudFormation, S3, IAM and KMS actions are added.
The CF actions are used to deploy the CF templates into this account, S3 actions are needed to get the artifacts from the Central Account and KMS actions are needed to decrypt the artifact.
Looking at the cloudformationdeployer-role or better the according policy we see that this role gets similar actions like CentralAcctCodePipelineCFRole. Supplementary some IAM, Lambda and API Gateway actions are added.
All these actions are needed to create our application:
IAM actions to create all needed roles/policies
Lambda actions to create our serverless functions
API Gateway actions to create endpoints of the application
If you will use this example to deploy your own applications to multiple AWS accounts this role/policy has to be customized to fit your needs.
All actions which will be needed to deploy your application have to be added here.
Let’s look at the last template,
This template which will be used in the Central account creates only one resource, the CodePipeline. As you can see this CodePipeline will use the KMS Key as encryption key and will use the S3 bucket as artifact store.
We see 5 stages:
Getting the source from CodeCommit
Build the templates with CodeBuild
Create/deploy change sets to Dev account
Create/deploy change sets to Test account
Create/deploy change sets to Prod account
CodeCommit and CodeBuild stages are easy to understand, no magic there, but let’s look at the create/deploy change sets to the different accounts:
The key point here are the values used for RoleArn’s and that you can define roles for the creation/execution of CloudFormation change sets.
This is the role (CentralAcctCodePipelineCFRole) used by the CodePipeline in the Central account to execute the CloudFormation template in the Dev account.
The role was created on the Dev account with the 02prereqs-accounts.yaml template but the ARN value can be calculated.
This is done in the 01central-prereqs.yaml template and imported here in this template 03central-pipeline.yaml.
Snippet from 01central-prereqs.yaml:
The second role (cloudformationdeployer-role) is used to deploy the resources inside the Dev account which are defined in the CloudFormation template. That’s the same IAM Role setting which you will see if you manually deploy a CloudFormation stack under "Configure stack options" → "Permissions"
As you can see the RoleArn is defined inside the Configuration part of the Create/Execute change set. This is the role/policy we saw before which has to be customized to fit your needs if you will use this example to deploy your own applications to multiple AWS accounts.
Hope this Part 2 gave you more details on how this example works & how you can customize it.
The magic happens at the RoleArn that are used at the different CodePipeline stages!
The beauty of this is that if you have a working solution like this you can reuse it almost everywhere.
Comments and questions are welcome or contact me on Twitter.