Don't create a gazillion kms keys

[jellevandenhooff]

Note: for support questions, please first reference our documentation, then use Stackoverflow. This repository's issues are intended for feature requests and bug reports.

• I'm submitting a ...

  • 🪲 bug report
  • 🚀 feature request
  • 📚 construct library gap
  • ☎️ security issue or vulnerability => Please see policy
  • ❓ support request => Please see note at the top of this template.

• What is the current behavior?
  Things like codepipeline pipelines create a S3 bucket and corresponding KMS key per pipeline.

• What is the expected behavior (or behavior of feature suggested)?
  Create fewer KMS keys.

• What is the motivation / use case for changing the behavior or adding this feature?
  That is going to add up pretty quickly, and is also difficult to clean up afterwards since the KMS key is not deleted automatically.

• Please tell us about your environment:

  • CDK CLI Version: 0.39.0
  • Module Version: 0.39.0
  • OS: all
  • Language: TypeScript

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. associated pull-request, stackoverflow, gitter, etc)

[skinny85]

Hey @jellevandenhooff ,

if you don't want to have the default behavior of creating the keys, feel free to provide your own Bucket when creating the Pipeline:

new codepipeline.Pipeline(this, 'Pipeline', {
  artifactBucket: new s3.Bucket(this, 'Bucket'),
  // ...
});

Is this good enough to solve your problem?

Thanks,
Adam

[jellevandenhooff]

Hi! Thanks. That’s what I ended up doing, but I wish I didn’t have to be on the hunt for keys created by other modules.

…

On Wed, Jul 10, 2019 at 16:56 Adam Ruka ***@***.***> wrote: Hey @jellevandenhooff <https://github.com/jellevandenhooff> , if you don't want to have the default behavior of creating the keys, feel free to provide your own Bucket when creating the Pipeline: new codepipeline.Pipeline(this, 'Pipeline', { artifactBucket: new s3.Bucket(this, 'Bucket'), // ... }); Is this good enough to solve your problem? Thanks, Adam — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3275>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACIGLHFLEJP2LLXOONBTGLP6ZZKFANCNFSM4IADCNUA> .

[skinny85]

It's kind of a chain of related issues that leads to this final state. We want to provide a secure default, so we encrypt the Bucket. However, CloudFormation cannot remove a Bucket that has any contents inside; so, to save you from having to go to the CloudFormation console every time you attempt to remove the Bucket from your Stack, we orphan it instead. Now, because we set a Key for it, we shouldn't really remove the Key either (as you wouldn't be able to read any of the contents of the Bucket if the Key was gone). So, we have to orphan the Key as well.

And that's why you get a Bucket + Key per created Pipeline by default.

[bgdnlp]

Wouldn't SSE-S3 be a better default in the sense that it would be less surprising?

[skinny85]

Unfortunately, SSE-S3 does not cover all scenarios - in particular, cross-account access. We feel like the cross-account use case is important enough for CodePipeline that the default setup should work for it.

I'm going to close this issue; @bgdnlp @jellevandenhooff if there's anything you'd like to add to the discussion, please comment here, and I'll reopen it.

Thanks,
Adam

[skinny85]

Good news - we will add an Alias to the default KMS Key created with the Pipeline, which should make it easy to hunt them down in the console. See #3694