2

I made the CodePipeline to build the source code from CodeCommit to ECR by cdk

When deploying this cdk code, somehow the key named like this

codepipeline-cdkmynavirepomynavipipelinefe7f8d68 is made in KMS customer managed key

I am not sure why this is made, and I don't want to use this.

Why or where this key is made?

const adminPipeline = new codepipeline.Pipeline(this, 'mynaviPipeline', {
  pipelineName: 'cdk-mynavi-pl',
});


const mynavi_cc_repo_name = 'cdk-mynavi-cc'
const mynavi_cc_repo = new codecommit.Repository(this,
  "mynavi-cc-repo",{
    repositoryName: mynavi_cc_repo_name,
    description:"for resizer repo"
})

const adminBuildProject = new codebuild.PipelineProject(this, 'adminBuildproject', {
  environment: {
    buildImage:codebuild.LinuxBuildImage.STANDARD_4_0,
    privileged:true, 
  },
  buildSpec: codebuild.BuildSpec.fromSourceFilename("./buildspec.yml")
});
const adminSourceOutput = new codepipeline.Artifact();
const adminSourceAction = new cdk.aws_codepipeline_actions.CodeCommitSourceAction({
  actionName: 'AdminSource',
  repository: mynavi_cc_repo,
  output: adminSourceOutput,
  trigger:  cdk.aws_codepipeline_actions.CodeCommitTrigger.POLL,
})

const dockerHubSecretArn = 'arn:aws:secretsmanager:ap-northeast-1:678100228231:secret:docker_login-TBFA5B';
const dockerHubSecret = secretsmanager.Secret.fromSecretCompleteArn(this, 'SecretFromCompleteArn', dockerHubSecretArn);

dockerHubSecret.grantRead(adminBuildProject)

cronEcrRepo.grantPullPush(adminBuildProject)
djangoEcrRepo.grantPullPush(adminBuildProject)
nginxEcrRepo.grantPullPush(adminBuildProject)

const adminBuildOutput = new codepipeline.Artifact();
const adminBuildAction = new cdk.aws_codepipeline_actions.CodeBuildAction({
  actionName: 'AdminCodeBuild',
  project: adminBuildProject,
  input: adminSourceOutput,
  outputs: [adminBuildOutput]
});

adminPipeline.addStage({
  stageName: "mynaviSource",
  actions: [adminSourceAction],
});
adminPipeline.addStage({
  stageName : "mynaviBuild",
  actions: [adminBuildAction]
});
baduker
  • 19,152
  • 9
  • 33
  • 56
whitebear
  • 11,200
  • 24
  • 114
  • 237

2 Answers2

3

It has to do with encryption at rest.

Data in CodePipeline is encrypted at rest using AWS KMS keys. Code artifacts are stored in a customer-owned S3 bucket and encrypted with either the AWS managed key or a customer managed key.

Encrypting codepipline artifacts is enabled by default.

If you choose the default option for encrypting code artifacts, CodePipeline uses the AWS managed key. You cannot change or delete this AWS managed key.

You cannot disable the encryption, but you can choose how you encrypt the artifacts.

The good thing is that if you go with the default option, you don't have to manage the encryption keys.

This can be, for example, selected in the CodePipeline console:

enter image description here

More on Data Protection in AWS CodePipeline.

baduker
  • 19,152
  • 9
  • 33
  • 56
1

OP asked why the CDK pipeline used an unwanted KMS customer managed key by default, which isn't directly addressed in the accepted answer. I'll try to address the why here.

Since policies for AWS managed keys cannot be updated or replaced, the flexibility of customer managed key policies is needed in at least two cases:

  1. Least privilege security: AWS managed key policies allow any principle within the same account to decrypt the artifacts. Using a customer managed key to more tightly control permissions within a single account is optional, but it's considered a best practice. It can be skipped in order to avoid the additional cost and management hassle. However, one could argue that it's even more important to use the Principle of Least Privilege (PoLP) for single account deployments that don't leverage the hard boundaries of cross-account deployments.

  2. Cross-Account Deployments: AWS managed key policies cannot be updated or replaced to configure cross-account permissions. So least privilege security aside, customer managed keys (or customer provided keys) are required to enable any cross-account artifact access due to their customizable policies.

Given these two cases and the CDK team presumably wanting to configure best practices by default, it's no surprise that crossAccountKeys: true is the default for pipelines. However, for those experimenting with the CDK in single account non-production deployments and likely leveraging the Free Tier, those KMS key charges can start to add up. I think that's why CDK now bootstraps accounts without a customer managed key for the default bucket unless you set a CLI flag for it.

OP didn't directly mention it, but since OP in this comment said setting crossAccountKeys: false solved the problem, it implies OP was working in a single account. While this may be ok as a convenience for e.g. exploring AWS in sandbox accounts, I suggest still going to the trouble of using customer managed keys towards least privilege access once things get more serious and closer to production.

rob3c
  • 1,936
  • 1
  • 21
  • 20