3 ms·

Can you tell us more about the key management you sovled for the internal CI? Sounds like you needed a CA?

brabel 5y ago
We have a lot of different repositories and internal as well as open source libraries we maintain. We publish things to our internal Nexus when it's internal, and Maven Central when it's public. Because our product is used in high security scenarios, we needed a way to verify that every artifact we download (from the repos mentioned above) during the CI build is signed to guarantee that if our repositories have been compromised, we won't end up with compromised artifacts being brough into our product anyway (because the signing keys are kept securely in the CI agents, which we trust much more than the repositories as, for example, they are not exposed on the Internet). So we needed signing keys in the CI agents, and we needed verification public keys (that we trust) in the releaser "machine" (which downloads everything and puts it together for the final build). We also needed the releaser machine to re-sign everything for publication on Maven Central and our distribution website, which our customers use to download it from and can also verify our signature on every artifact. You're right that a sort of CA could help, but as I understand it, with PGP you don't need that in our case because all keys are controlled by us, so it's easy for us to trust keys and generate new keys as we spawn new agents. This means our CI master has to have the master key, otherwise it couldn't sign other agent's keys... which is a bit of a problem but we think it's still fine because our master CI is well protected (and if that gets compromised, everything else falls anyway). It's been working well, but it was complicated to setup and it's a bit inconvenient to use when we do a full product release (it involves updating all keys locally as they're generated for CIs as I mentioned)...

We have a lot of different repositories and internal as well as open source libraries we maintain. We publish things to our internal Nexus when it's internal, and Maven Central when it's public. Because our product is used in high security scenarios, we needed a way to verify that every artifact we download (from the repos mentioned above) during the CI build is signed to guarantee that if our repositories have been compromised, we won't end up with compromised artifacts being brough into our product anyway (because the signing keys are kept securely in the CI agents, which we trust much more than the repositories as, for example, they are not exposed on the Internet). So we needed signing keys in the CI agents, and we needed verification public keys (that we trust) in the releaser "machine" (which downloads everything and puts it together for the final build). We also needed the releaser machine to re-sign everything for publication on Maven Central and our distribution website, which our customers use to download it from and can also verify our signature on every artifact. You're right that a sort of CA could help, but as I understand it, with PGP you don't need that in our case because all keys are controlled by us, so it's easy for us to trust keys and generate new keys as we spawn new agents. This means our CI master has to have the master key, otherwise it couldn't sign other agent's keys... which is a bit of a problem but we think it's still fine because our master CI is well protected (and if that gets compromised, everything else falls anyway). It's been working well, but it was complicated to setup and it's a bit inconvenient to use when we do a full product release (it involves updating all keys locally as they're generated for CIs as I mentioned)...