Allow user to specify full KMS key ARN for pipeline signing. #1422
Conversation
We have a use case where we want to have a single KMS key that Buildkite agents in multiple accounts can use to sign and verify pipeline steps. By letting the user specify the whole key ARN rather than just the key ID, the user is free to use a key wherever they want. * templates/aws-stack.yml: Rename PipelineSigningKMSKeyId to PipelineSigningKMSKeyArn and avoid assuming the key is in the same account/region as the agent stack. Co-authored-by: Matty Boyles <[email protected]>
|
(for what it's worth, this patch worked well for us and we are now able to use a cross-account KMS key) |
|
@toothbrush This is a good suggestion, I am not sure it is wise to change the current field as it will suprise poeple using this currently. I 100% want to enable the feature though, not sure if you had thoughts on how we could support both? |
I agree, i think we can provide a more seamless way at the expense of a bit more complex CloudFormation.
I appreciate the attitude! We were thinking that it should be possible to support both We didn't want to dive straight in and do that given the complexity, but since you're open to the idea, we'll have a crack and see what comes out. Thanks @wolfeidau! |
|
@wolfeidau Please see alterative PR here: #1424 |
Description
We have a use case where we want to have a single KMS key that Buildkite agents in multiple accounts can use to sign and verify pipeline steps. By letting the user specify the whole key ARN rather than just the key ID, the user is free to use a key wherever they want.
We are aware that this is a breaking change, which is not ideal (i.e., if a user has already specified the
PipelineSigningKMSKeyIdparameter, they'll need to replace it withPipelineSigningKMSKeyArn). Please let us know if it'd be better to accept either/or key ID or ARN -- the reason we didn't implement the change like that off the bat is that as far as we could tell, that'd add a bunch of ugly if-statements everywhere to check which had been provided and do slightly different things accordingly.CHANGELOG
PipelineSigningKMSKeyIdtoPipelineSigningKMSKeyArnand avoid assuming the key is in the same account/region as the agent stack.