Stack/BuildPipeline/ArtifactsBucketEncryptionKeyAlias fails to get recreated when cdk deploy follows cd destroy

[vgribok]

A .NET CDK 1.9 (and then 1.10) project that builds a CodePipeline with CodeCommit and CodeBuild stages, fails when cdk deploy is run after cdk destroy with the error messages saying "XxxxxxxStack/BuildPipeline/ArtifactsBucketEncryptionKeyAlias (BuildPipelineArtifactsBucketEncryptionKeyAliasXXXXXXXX) alias/codepipeline-somepipelineb5eb558e already exists"
Since a KMS key can only be deleted only after at least 7 days later, the region where this error happens makes the region unusable for the CDK project for at least 7 days!

Reproduction Steps

1. Build a stack including CodePipeline containing CodeCommit and CodeBuild. Deploy with cdk deploy
2. Trigger a build that will check out source into an artifact.
3. Run cdk destroy.
4. Run cdk deploy again. Observe error above"
5. Try to delete or rename the KMS key alias - cannot be done as it's not meant to be. KMS key can be scheduled to be deleted in nor earlier than 7 days.

Error Log

XxxxxxxStack/BuildPipeline/ArtifactsBucketEncryptionKeyAlias (BuildPipelineArtifactsBucketEncryptionKeyAliasXXXXXXXX) alias/codepipeline-somepipelineb5eb558e already exists

Environment

• CLI Version : 1.10
• Framework Version: 1.10
• OS : Windows 10
• Language : C#/.NET

Other

19/28 | 5:39:18 PM | CREATE_FAILED | AWS::KMS::Alias | CicdInfraAsCodeStack/BuildPipeline/ArtifactsBucketEncryptionKeyAlias (BuildPipelineA
rtifactsBucketEncryptionKeyAlias68E67B02) alias/codepipeline-cicdinfraascodestackbuildpipelineb5eb558e already exists
new Alias (C:\Users\username\AppData\Local\Temp\jsii-kernel-AAuzoS\node_modules@aws-cdk\aws-kms\lib\alias.js:69:26)
_ new Pipeline (C:\Users\username\AppData\Local\Temp\jsii-kernel-AAuzoS\node_modules@aws-cdk\aws-codepipeline\lib\pipeline.js:86:13)
_ C:\Users\username\AppData\Local\Temp\dcqv0cxm.fwo\jsii-runtime.js:6798:49
_ Kernel._wrapSandboxCode (C:\Users\username\AppData\Local\Temp\dcqv0cxm.fwo\jsii-runtime.js:7250:20)
_ Kernel._create (C:\Users\username\AppData\Local\Temp\dcqv0cxm.fwo\jsii-runtime.js:6798:26)
_ Kernel.create (C:\Users\username\AppData\Local\Temp\dcqv0cxm.fwo\jsii-runtime.js:6552:21)
_ KernelHost.processRequest (C:\Users\username\AppData\Local\Temp\dcqv0cxm.fwo\jsii-runtime.js:6327:28)
_ KernelHost.run (C:\Users\username\AppData\Local\Temp\dcqv0cxm.fwo\jsii-runtime.js:6270:14)
_ Immediate._onImmediate (C:\Users\username\AppData\Local\Temp\dcqv0cxm.fwo\jsii-runtime.js:6273:37)
_ processImmediate (internal/timers.js:439:21)

---

This is 🐛 Bug Report

[skinny85]

Hey @vgribok ,

thanks for opening the issue. I think there's a few things you can do here:

1. Remove the Alias from the AWS CLI. I'm pretty sure an Alias can be removed without removing the underlying Key (only the Key has the 7 day grace period).
2. The Key is there only by default. You can pass an explicit Bucket when creating the Pipeline, one that doesn't have a Key (or a different Key, possibly with a different Alias):

const myArtifactBucket = new s3.Bucket(this, 'Bucket', {
  // possibly pass a Key, maybe with an Alias, here?
  // ...
});

const pipeline = new codepipeline.Pipeline(this, 'Pipeline', {
  artifactBucket: myArtifactBucket.
  // ...
});

Let me know if this helps!

Thanks,
Adam

[skinny85]

Actually, I just thought of an even simpler way: just change the logical ID you have of your Pipeline (for example, if the current logical ID is 'Pipeline', change it to something like 'MyPipeline', or 'Pipeline2'). That will make it create an Alias with a different name, and avoid the conflict.

[vgribok]

@skinny85 Thank you for suggested workarounds. I used aws kms delete-alias --alias-name alias/codepipeline-pipelineNameXxxxx and it did let me move past this issue. Hopefully, this issue will be fixed to achieve parity between cdk deploy and cdk destroy, so that it would not be necessary to do manual/scripted cleanups after cdk destroy before running next cdk deploy.

[skinny85]

Actually, it was customer feedback that made us add the Alias, and not remove it :) The complaint was that otherwise, we're generating KMS keys that the customers have no idea were used in a CodePipeline (because of the lack of a human-readable alias), and so they're not sure they can remove, accumulating junk in their accounts.

[vgribok]

I can certainly see that, but then subsequent cdk deploy should not be failing, by either reusing the existing key or creation a new one with randomized suffix appended to the name. WDYT?

[skinny85]

That would be ideal, but unfortunately we can't do that :( Aliases cannot be automatically named by CloudFormation (you are required to provide them a name), and we must auto-generate stable names (if the names were different between 2 versions of the CDK-resulting template without any code changes, it would result in a replacement of the alias each time you did cdk deploy).

I understand this is not ideal, but I think this is the best we can with the tools at our disposal.