If I understand correctly, this is meant for use by individual devs, each signing their own commits and tags. How is this better than each dev having their own signing key living on their own machine? I see a lot more of “going rogue” potential in this system.
I understood it a bit differently, this approach is trying to add the same guarantees (as developers signing their commits and tags) to the outputs of the CI.
With it, the CI system can sign a commit or, more commonly, a release tag at the same time and using the same role and key material as the other deployable artefacts in the release.
Not quite, this is more useful for the CI build agents that are often next in the chain. So after your devs have signed individual commits and those commits are being rolled up into deployable artefacts by the CI system.
The CI system can authenticate to Vault as its “CI system identity” to sign those artefacts to mark them as deployable after having passed whatever rigour is appropriate, and the subsequent deployment environments verify the signature upon admission.
This tool is one way to do that when the “deployable artefacts” in question are actually just e.g. IaC files on a branch instead of binaries or tarballs. There’s other ways to achieve this chain of custody of course. One simply being tarballing up the branch or copying its HEAD SHA into a file and signing that. Another I’ve read about (but can’t remember from where) is the propagation of dev’s user identity into the CI stage if you’re on the AWS stack, using their SSO and Code* products.
If I understand correctly, this is meant for use by individual devs, each signing their own commits and tags. How is this better than each dev having their own signing key living on their own machine? I see a lot more of “going rogue” potential in this system.
I understood it a bit differently, this approach is trying to add the same guarantees (as developers signing their commits and tags) to the outputs of the CI.
Yep sorry, ended up replying on top of you. This is what was meant in the post.
Not quite, this is more useful for the CI build agents that are often next in the chain. So after your devs have signed individual commits and those commits are being rolled up into deployable artefacts by the CI system.
The CI system can authenticate to Vault as its “CI system identity” to sign those artefacts to mark them as deployable after having passed whatever rigour is appropriate, and the subsequent deployment environments verify the signature upon admission.
This tool is one way to do that when the “deployable artefacts” in question are actually just e.g. IaC files on a branch instead of binaries or tarballs. There’s other ways to achieve this chain of custody of course. One simply being tarballing up the branch or copying its HEAD SHA into a file and signing that. Another I’ve read about (but can’t remember from where) is the propagation of dev’s user identity into the CI stage if you’re on the AWS stack, using their SSO and Code* products.
Ah, so if I understand correctly this would be more likely to be used for signed tags than commits? That makes sense, thanks!