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

And also, this is a new kind of statefulness which requires deployment-time manual steps. It is also a backwards-incompatible feature released in a minor version, which isn’t ideal for a module marked stable. You changed the default, mind you.

Doesn’t the same kind of question of aliases-for-clarity apply to all other places where CDK defaults to using KMS encryption? Why just with pipelines? To my mind consistency across the CDK is more important. On the usability level it’s good to remember that many of us deploy and tear down pipelines several times a day – it’s a very common occurrence.

This is a case of CDK trying to be too clever, thereby shooting its users in the foot. What you have done is prompt people to use unencrypted buckets because the abstractions you more or less randomly have added now make pipelines too cumbersome to use. We suddenly find us having painted ourselves into a corner without knowing it, as we now have aliases which need special care. That’s a breaking change we didn’t ask for, and in a minor release.

I think you should bring up the issue of reverting the alias feature with the team. It needs to be rethought, and there ought to be a discussion about the principles of CDK’s use of extra abstraction in general.

However. If this situation indeed isn’t a bug but a feature requiring manual steps – without which a redeploy after a destroy will fail – then this forces certain architectural decisions when using CDK. That’s less ideal in my opinion; CDK should widen, not narrow down our options.

In my particular use case, I will have to resort to either using manually managed KMS keys (and set up procedures around them with devs and ops and write appropriate installation and maintenance sections in the relevant runbooks), a non-encrypted bucket, or a custom resource which handles the existence of the alias.

Can you explain why CDK narrows your options here? Why not use something like this in your code:

const bucket = new s3.Bucket(this, 'ArtifactBucket', {
  encryption: s3.BucketEncryption.KMS, // encrypted bucket with a key, _without_ an alias! 
  // ...
});

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

or even this:

// no alias, key destroyed on `cdk destroy`
const key = new kms.Key(this, 'Key', {
  removalPolicy: RemovalPolicy.DESTROY,
  // ...
});
// bucket destroyed on `cdk destroy`, but only if it's empty!
const bucket = new s3.Bucket(this, 'ArtifactBucket', {
  encryptionKey: key,
  removalPolicy: RemovalPolicy.DESTROY,
  // ...
});
const pipeline = new codepipeline.Pipeline(this, 'Pipeline', {
  artifactBucket: bucket,
  // ...
});

The issue is not whether what you’ve done makes sense. The issue is consistency across the CDK, backward compatibility, introducing breaking changes in minor versions, and increasing the learning curve of CDK. It’s the CDK team’s cavalier attitude towards semantic versioning. It’s not understanding that adding abstractions in an opaque way to projects which already are underway whilst at the same time disregarding the conventions of semantic versioning makes professional projects considerably more difficult to manage. It’s not understanding that how the CDK team currently does things will lead to rejection of CDK as a tool in any kind of controlled environment.

I’ll explain our use case in detail privately to you and Elad – security concerns prevent me from doing so publicly – for it is important that you understand who we are and where we’re coming from.

Thanks!

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