in-toto / witness

Witness is a pluggable framework for software supply chain risk management. It automates, normalizes, and verifies software artifact provenance.
https://witness.dev
Apache License 2.0
409 stars 57 forks source link

cosign support in witness: keyless signatures via OIDC issuer #76

Closed shibumi closed 1 year ago

shibumi commented 2 years ago

I am reading the code for the signature generation right now. I see that we are using x509 certificates for signing already. Would it make sense to support keyless signatures via OIDC-issuer, either via Email-based OpenIDs or via Workload Identities. The first would make sense if a human signs the attestations. The latter makes sense if witness runs in a CI environment and there should be no interaction that needs manual intervention.

If you are not up to date with keyless signatures here is a short walkthrough:

You might know the OpenID Connect standard. The OpenID Connect standard allows identifying yourself via your email to a foreign system. For example, when you login into a new website via your Github ID you are doing this via OpenID Connect.

The sigstore project is currently pushing the idea that we could use this user identity to generate an ephemeral certificate key pair for signing operations. This has the huge advantage that the user does not need to care about private key management at all. No keys in a cold storage, no key backups, no potential key leaks. The only thing the user has to care about is securing their Identity, for example via 2FA.

Workload identities are working the same way. The only difference is that a workload identity is coupled to the CI Pipeline. In terms of Github Actions github will create a token, only valid for this one pipeline run, and sigstore uses that token to generate an ephemeral key pair and so on.

The cosign library manages most of this (including uploading the signature(s) to the rekor transparency log). The transparency log can be compared to a https certificate transparency log... it tracks all signing operations + stores the used public certificate and a digest of the artifact.

On the long term I would like to have this feature in in-toto-golang as well, but unfortunately I am afraid, that we need to make huge changes in in-toto-golang. First step could be a Signer interface (right now most signing operations are pretty much hard coded).

I don't know if this is a feature for witness or for in-toto-golang. As far as I understand the code in witness, you are not using in-toto-golang's signing features at all, right?

colek42 commented 2 years ago

This is definitely on the roadmap, but not on our critical path right now as our reference architecture utilizes SPIFFE/SPIRE. We would accept any PRs adding support for Fulcio generated certs.

mikhailswift commented 2 years ago

I don't know if this is a feature for witness or for in-toto-golang. As far as I understand the code in witness, you are not using in-toto-golang's signing features at all, right?

We're not importing in-toto-golang's signing code but all of the signing schemes and what not should be compatible with in-toto-golang's. Using RSA-PSS by default, for example.

As Cole mentioned cosign's OIDC issuer is definitely of interest for us. I believe SPIFFE/SPIRE is a better solution for workload identities in high compliance environments but it isn't as nice for human interaction, where this wins out.

colek42 commented 2 years ago

Code sample on how to fetch a cert from fulcio here: https://github.com/sigstore/fulcio/pull/324

colek42 commented 2 years ago

We will need to get Fulcio set up to work on this issue.

colek42 commented 2 years ago

First MR will be to support witness sign to enable OIDC signing of policy.

colek42 commented 1 year ago

We support Fulcio keyless, I'll open other issues specific to Rekor and CA/timestamp policy verification