I’m worried that our CodePipeline service role has too many permissions. It currently has 'AdministratorAccess' which is a huge security risk. I want to narrow it down to only what’s necessary for CodeBuild and S3. What are the specific actions I need to allow for a standard CI/CD flow, and how do I handle cross-account resource access securely?
3 answers
Scoping down a CodePipeline role is tedious but necessary. You should start by removing Admin access and adding 's3:Get*' and 's3:Put*' limited to only your artifact bucket. For CodeBuild, you need 'codebuild:StartBuild' and 'codebuild:BatchGetBuilds'. For cross-account access, you shouldn't use long-term keys; instead, use STS to assume a role in the target account. This requires a trust relationship where the target account trusts your pipeline's service role. This setup ensures that even if the pipeline is compromised, the "blast radius" is limited to only specific resources.
How do you handle the KMS encryption keys when moving artifacts between S3 buckets in different accounts? I’ve noticed that if the KMS policy doesn't explicitly allow the pipeline's role from the other account, the 'Deploy' stage fails with an 'Access Denied' error even if the S3 permissions are correct.
Always use 'Condition' blocks in your IAM policies to restrict actions to specific VPCs or IP ranges. This adds an extra layer of security beyond just resource-level permissions.
Great tip, Linda. Using the 'aws:SourceVpc' condition ensures that the pipeline can only be triggered or modified from within your corporate network or management VPC.
You hit the nail on the head, Mark. You must update the KMS Key Policy in the "Source" account to include the IAM Role ARN from the "Target" account under the 'kms:Decrypt' action. Without this, the deployment agent can see the file in S3 but can't actually read the contents to deploy them. It's one of the most common "hidden" errors in multi-account AWS DevOps setups.