Open ldecaro opened 2 years ago
I'm missing some context here.
Standardize the KMS aliases using alias/codepipeline* which seems to be the actual standard.
What do you mean "actual standard"? Who defined this standard?
In a cross-region scenario another KMS key gets created in another region. This KMS key has an alias that does not follow the pattern alias/codepipeline*.
Wouldn't all steps have that exact same problem though? Why do you need to add permissions to a prefix to your CodeDeploy step? What do other steps do?
Hi @rix0rrr thanks for looking into this. Yes, I agree with you and would like to provide some more context.
I create a pipeline using CDK Pipelines. One stage is the deploy stage and a stack is deployed using CodeDeploy. When the stack is deployed in the same region where the pipeline is, CodeDeploy role will need grant to Decrypt the code pipeline artifact, encrypted using a KMS key. All the pipelines that get created using CDK Pipelines come with a KMS key that has a random name and a random alias but it seems that the alias starts with the following prefix: codepipeline* no matter what the pipeline name is. An example: codepipeline-ecsmicroservicetoolchainecsmicroservicecodepipelinepipelinebcd0bf07
When, from my deploy stage, I deploy a stack in a remote region that will execute a CodeDeploy action, note I'm talking in general terms because this happens on every pipeline, the CDK Pipeline would also deploy another stack in the remote region that creates a S3 bucket, a KMS Key, a KMS Key Alias to host the artifact that is about to (automatically) be sent to the region where the stack from the deploy stage is going to be deployed. I'm talking about the -support- stack.
This key that is created by the -support- stack, also manages encryption of the codepipeline artifact, now in a S3 bucket, in another region. In this case, I wonder whether the alias associated with this other KMS key could also come with the same prefix codepipeline*.
The use case is simple. I'm creating another layer of abstraction on top of CDK Pipelines. I want to deploy one role that has access to all the keys managed by CDK Pipelines in the account. A condition to allow the Decrypt if using KMS keys with the alias codepipeline* would allow for a more generic work.
Thanks for elaborating your use case here @ldecaro,
I believe the Key and alias end up getting generated here https://github.com/aws/aws-cdk/blob/1ef0af8dfe6dfb9653338ea9daa6a60d8cbd8ccb/packages/%40aws-cdk/aws-codepipeline/lib/private/cross-region-support-stack.ts#L65-L75
And here's the logic which determines the name https://github.com/aws/aws-cdk/blob/1ef0af8dfe6dfb9653338ea9daa6a60d8cbd8ccb/packages/%40aws-cdk/aws-codepipeline/lib/private/cross-region-support-stack.ts#L11-L28
Simply changing the const value REQUIRED_ALIAS_PREFIX to alias/codepipeline
would work for your use case I believe, however this would modify existing aliases for customers. Could potentially change this with a feature flag
Hi @peterwoodworth thanks for the feedback. I would love to have this added as a feature flag. Thanks!
Describe the bug
Hi, in a single region deployment I have a CodeDeploy action implementing a Step and using files from an artifact. The CodeDeploy action will Decrypt the codepipeline artifact on S3 using the KMS key with alias alias/codepipeline*.
In a cross-region scenario another KMS key gets created in another region. This KMS key has an alias that does not follow the pattern alias/codepipeline*.
This makes it hard to work with CDKPipelines and create a CodeDeploy execution role that has an IAM Decrypt statement with a condition allowing to use KMS keys based on a range of aliases like the clause below:
Expected Behavior
In cross-region deployments, the KMS keys associated with the artifact that gets moved to the target region should have aliases following the standard alias/codepipeline*
Current Behavior
A generic alias that doesn't seem to follow any standard is created.
Reproduction Steps
Anything that is deployed using cross account stack and CodeDeploy. When CodeDeploy tried to Decrypt the artifact from S3 it would need to use a KMS key that has a different alias prefix than alias/codepipeline*
Possible Solution
Standardize the KMS aliases using alias/codepipeline* which seems to be the actual standard.
Additional Information/Context
N/A
CDK CLI Version
2.20.0
Framework Version
N/A
Node.js Version
v
OS
AmazonLinux
Language
Java
Language Version
Java(8)
Other information
It would be great if all CDKPipelines KMS keys came with standard alias prefixes as in alias/codepipeline* or at least for the scenario described above..