Allow user to specify full KMS key ARN for pipeline signing.

[toothbrush]

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 PipelineSigningKMSKeyId parameter, they'll need to replace it with PipelineSigningKMSKeyArn). 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

• templates/aws-stack.yml: Rename PipelineSigningKMSKeyId to PipelineSigningKMSKeyArn and avoid assuming the key is in the same account/region as the agent stack.

[toothbrush]

(for what it's worth, this patch worked well for us and we are now able to use a cross-account KMS key)

[wolfeidau]

@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?

[toothbrush]

@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 agree, i think we can provide a more seamless way at the expense of a bit more complex CloudFormation.

I 100% want to enable the feature though, not sure if you had thoughts on how we could support both?

I appreciate the attitude! We were thinking that it should be possible to support both PipelineSigningKMSKeyId and PipelineSigningKMSKeyArn parameters, with assertions that you can only provide one, and logic in the template to construct the ARN based on whichever field the user provided.

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!

[MathewBoyles]

@wolfeidau Please see alterative PR here: #1424

[toothbrush]

Hey @wolfeidau, i'm wondering if, since the holiday period, you've had a chance to consider our various approaches to this problem? Hopefully one of them will be acceptable to you:

• Allow user to specify full KMS key ARN for pipeline signing. #1422: this PR, which is not backwards compatible
• Allow ARN to be provided for pipeline signing KMS key #1424: more machinery, but allows existing users of the feature to keep using their config unchanged
• Let user provide full KMS Key ARN, take 3 #1425: slightly less machinery, still backwards compatible.

Thank you for considering our change request! 🙏

[wolfeidau]

@toothbrush I have seen these come through, just busy helping out with other issues.

I will be back on board next week to look at this, I really want to try this out internally 😅

[toothbrush]

@toothbrush I have seen these come through, just busy helping out with other issues.

I will be back on board next week to look at this, I really want to try this out internally 😅

Glad to hear it – and welcome back!