Mstar0816
commented
4 months ago Until something else comes along. It's quite interesting to see how authN/authZ solutions continue to evolve. OIDC is super convenient for a lot of reasons. We are implementing its use for CICD-related activities in related systems that support it. However, a lot of tools or even major cloud providers are lagging behind with support for integrations using OIDC, unfortunately.
'Keyless' signing of git commits is an interesting use case. Though, I suppose what 'keyless' really means is that you entrust a custodian to generate/hold your keys and use it appropriately. This is something that's been extremely valuable with other kinds of cryptographic keys like TLS/SSL certificates (think AWS Certificate Manager).
But I think OIDC lacks some capabilities (or needs additional solutions on top of OIDC) that enterprises need for certain use cases. For example, the ability to revoke tokens/keys quickly or MFA requirements.
In practice, that means you won’t need GPG keys and a complicated setup in order to sign your Git commits. After installing and configuring Gitsign within your project and signing your commits, you will be redirected to a browser window to authenticate with a supported OpenID provider, such as GitHub or Google.
Signing details will then be stored in the transparency log Rekor for subsequent verification.
Why?
Cryptographically signing automatically generated Git commits significantly increases the security and traceability of your software supply chain.
Coupling short-lived X.509 certificates with ephemeral OIDC tokens ensures the integrity and authenticity of these changes, no matter their origin.