... or how to turn your single account AWS Code Pipeline into a multi-account one.
Recently I had an opportunity to improve the security posture of an application landscape which went to production in a bit of a rush so certain compromises were made on the way. Now that the applications have been running in a stable manner for some time, the time has come to make some security improvements.
Current Stage
In the current stage, multiple applications are running in the same AWS account together with all the other components such as the whole deployment pipeline, ECR repository, S3 buckets with artifacts and so on.
There are multiple ways how to improve the security posture of this landscape.
In this post I will focus on one of the best practices in the Security Pillar of the AWS Well Architected Framework - SEC01-BP01 Separate workloads using accounts which says:
Establish common guardrails and isolation between environments (such as production, development, and test) and workloads through a multi-account strategy. Account-level separation is strongly recommended, as it provides a strong isolation boundary for security, billing, and access.
Desired outcome: An account structure that isolates cloud operations, unrelated workloads, and environments into separate accounts, increasing security across the cloud infrastructure.
Common anti-patterns: Placing multiple unrelated workloads with different data sensitivity levels into the same account.
... the anti-pattern being exactly our case.
Approach
I took the following steps to follow the AWS best practices and to improve the security posture of the workloads:
- Establish a new AWS Organization and setup Organization Units as per the AWS Best Practices for OUs, such as: Infrastructure, Workloads, etc.
- Create a separate AWS account for each application and its stage
- Create a separate AWS account for the CI/CD tooling, ECR, Artifacts and other shared services
- Create a separate AWS account for VPCs and Subnets, possibly a Transit Gateway and a VPN for on-premise connectivity, to control the networking layer from one place. Share the subnets to the application accounts using the AWS Resource Access Manager
- Modify the AWS CodePipelines to deploy the application into a different account
While the steps 1 thru 3 are quite straight forward, I will focus more on the step 4 and 5.
In the step 4 I'm introducing the subnet sharing concepts which comes with the benefits of its own and they will be summarized at the end of the article.
Now let's have a look at the implementation changes needed for the Step 5.
Necessary Modifications for CI/CD Related Components
The existing components related to the deployments had to be modified, but to my surprise the list of changes isn't that long and the changes are rather straightforward and easy to implement.
IAM Roles in the Application Accounts
New roles have to be deployed in the target application accounts so that the Code Pipeline running in the Shared Services account can assume them and deploy the actual apps using Code Deploy.
The corresponding definition of such role would look like this. The needs to be replaced with the actual account ID of the Shared Services account.
The roles can be also deployed using CloudFormation Stacksets from the Management account using the Workloads OU as the target. This will ensure also scalability meaning that the stack set and the role will be deployed automatically to every new account created under that OU.
"RoleCodePipelineCrossAccount": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": "CodePipelineCrossAccountRole",
"Description": "Role assumed by CodePipeline from the Shared Services account",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<sharedsvcsaccid>:CodePipelineRole"
},
"Action": "sts:AssumeRole"
}
]
}
}
}
The role itself is used for multiple purposes. First it deploys a CloudFormation stack with the Code Deploy resources. Then it used again in a later stage to trigger a Code Deploy deployment. The necessary permissions could look like this, but could be scoped better:
{
"Action": [
"cloudformation:Describe*",
"cloudformation:CreateStack",
"cloudformation:DeleteStack",
"cloudformation:UpdateStack",
"iam:PassRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": [
"codedeploy:BatchGet*",
"codedeploy:CreateApplication",
"codedeploy:CreateDeployment",
"codedeploy:CreateDeploymentGroup",
"codedeploy:DeleteApplication",
"codedeploy:DeleteDeploymentGroup",
"codedeploy:Get*",
"codedeploy:List*",
"codedeploy:RegisterApplicationRevision",
"codedeploy:TagResource",
"codedeploy:UntagResource"
],
"Resource": "*",
"Effect": "Allow"
}
Since the role is used by CodePipeline to pull the artifacts from the S3 bucket, it needs the corresponding permissions for the S3 bucket, and also for the corresponding KMS key the bucket is encrypted with, so something like this:
{
"Action": [
"s3:Get*",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::<app-artifacts-bucket-in-sharedsvcs-account>/*",
"Effect": "Allow"
},
{
"Action": [
"kms:DescribeKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:<region>:<sharedsvcsaccid>:key/<keyid>",
"Effect": "Allow"
}
Code Pipeline IAM Role in the Shared Services Account
The Code Pipeline in the Shared Services account already has a role attached to it, so it just needs to be extended by the necessary permissions to assume the roles in the target application accounts:
{
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::<app-account-id>:role/CodePipelineCrossAccountRole"
],
"Effect": "Allow"
}
ECS/EC2 IAM Role in the Application Accounts
The role associated with the ECS task definition if you use ECS or the IAM role attached to EC2 if you deploy containers directly on EC2 needs to have the necessary permissions to pull images from the ECR in the Shared Services account and also for the KMS key associated with the ECR repository:
{
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchCheckLayerAvailability",
],
"Resource": "arn:aws:ecr:<region>:<sharedsvcsaccid>:repository/<reponame>",
"Effect": "Allow"
},
{
"Action": [
"kms:DescribeKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:<region>:<sharedsvcsaccid>:key/<ecrkeyid>",
"Effect": "Allow"
}
ECR Policy in the Shared Services Account
The ECR policy needs to allow the ECS/EC2 role in the Application account to pull the images from the repository:
{
"Sid": "AllowPushPull",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<app-account-id>:role/ECSRole"
]
},
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
]
}
ECR KMS Policy in the Shared Services Account
Since IAM roles from other accounts will pull images from the ECR repository, it needs to be encrypted with a Customer Managed Key as opposed to an AWS Managed Key. The corresponding policy would look as follows:
{
"Sid": "KeyUsage",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<app-account-id>:ECSRole"
},
"Action": [
"kms:DescribeKey",
"kms:Decrypt"
],
"Resource": "*"
}
Artifact S3 Bucket Policy in the Shared Services Account
Since Code Deploy that will pull artifacts from the S3 bucket is now located in the Application account, the bucket policy needs to enable that. It would look as follows:
{
"Sid": "AllowCrossAccountGetObject",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<app-account-id>:root"
},
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::<bucketname/*",
"Condition": {
"StringLike": {
"aws:PrincipalArn": [
"arn:aws:iam::<app-account-id>:role/CodeDeployRole"
]
}
}
}
Artifact S3 KMS Policy in the Shared Services Account
Similar to the ECR repo, also the S3 bucket storing the Code Pipeline artifacts needs to be encrypted with a CMK. The policy would look very similar to the ECR key policy, so I'm not going to repeat it here.
Necessary Modifications for the Code Pipeline Definition
The corresponding Code Deploy stages in the Code Pipeline need to be modified by adding the RoleArn parameters in the right places so that they assume a role in the target Application account to trigger the actual deployment. Below are two examples, one for a CloudFormation deployment and one for a Code Deploy deployment. For the Cloudformation, the second role is the role passed to the CloudFormation service to deploy the stack with.
"CodePipeline": {
"Type": "AWS::CodePipeline::Pipeline",
"Properties": {
"RoleArn": {
"Fn::Sub": "arn:aws:iam::${AWS::AccountId}:role/CodePipelineRole"
},
"Stages": [
{
"Name": "DeploySupportingInfra",
"Actions": [
{
"Name": "DeploySupportingInfra",
"ActionTypeId": {
"Category": "Deploy",
"Owner": "AWS",
"Version": 1,
"Provider": "CloudFormation"
},
"Configuration": {
...
"RoleArn": "arn:aws:iam::<app-account-id>:role/CloudFormationRole",
...
},
"RoleArn": "arn:aws:iam::<app-account-id>:role/CodePipelineCrossAccountRole",
...
}
]
},
{
"Name": "DeployApp",
"Actions": [
{
"Name": "DeployApp",
"ActionTypeId": {
"Category": "Deploy",
"Owner": "AWS",
"Version": 1,
"Provider": "CodeDeploy"
},
...
"Configuration": {
"ApplicationName": "...",
"DeploymentGroupName": "..."
},
"RoleArn": "arn:aws:iam::<app-account-id>:role/CodePipelineCrossAccountRole",
...
}
],
}
]
}
}
Architecture after the Changes
Below is a (simplified) diagram of what the final solution looks like. Better, isn't it?
Which benefits does the above approach bring?
Benefits of the Multi-account Approach
Following are the selected benefits of the general multi-account approach which are especially applicable to the above landscape:
Blast Radius Containment: compromised credentials or misconfigured resources in one account can't directly affect workloads in other accounts, limiting the damage from security incidents
Least Privilege Enforcement: IAM policies and SCPs can be scoped tightly per account or OU, making it easier to engineer and provide only the permissions each workload actually needs
CI/CD Pipeline Isolation: keeping deployment tooling in a dedicated account means pipeline credentials (which are often highly privileged) are separated from workloads. As such, tighter security controls can be applied to such account.
Separation of Duties: different teams can own different accounts with no ability to access each other's resources by default, enforcing organizational security boundaries at the infrastructure level rather than relying solely on IAM policies within a shared account
Benefits of Subnet Sharing Approach
There are multiple benefits of the shared subnets model compared to proliferation of individual VPC and subnets in each application account. These bring value from both security and operational perspective:
- Centralized Network Security Controls: A dedicated networking team owns and manages networking components such as route tables or NACLs in one place. Application teams can't accidentally (or intentionally) misconfigure network boundaries, reducing the blast radius of a misconfiguration. Furthermore, Service Control Policies can enforce restrictions on creation of VPC, Internet Gateways, etc., in the application accounts.
- Consistent Compliance Posture: Security baselines (e.g., flow logs enabled, subnet routing) are enforced at the network account level. You don't need to audit each application account independently — the network is already compliant by design.
- Exclusive Control Over External Connectivity: Only the central networking team can establish connections between the shared VPCs and the outside world — whether that's Transit Gateway attachments, VPC peering, Site-to-Site VPN, or Direct Connect. Application teams are not able to create unapproved network paths, backdoor connections, or unauthorized peering arrangements. This ensures all traffic entering or leaving the environment flows only through approved ingress/egress points, which is critical for meeting data sovereignty and compliance and lowers the risk of data exfiltration.
Top comments (0)