Decision how we want to do artifact signing

[Gerrit91]

In issue #228 we came across the topic to sign our artifacts with a tool like cosign.

If we would like to use cosign, we need to decide for the method to sign the artifacts.

Initially I started signing the artifacts using public and private keys (these are already put into the org CI secrets and can be used inside actions). Another option would be to use keyless signing as described here. Keyless signing makes verification a bit easier because we do not need to publish our public key somewhere.

Here is an example of how we could integrate cosign into our docker image builds including verification of the base image: metal-stack/oci-mirror#14

[Gerrit91]

We probably should also try out https://github.com/sigstore/policy-controller, maybe even install it in our mini-lab. This way we get a feeling for how users can verify our artifacts in their installations, too.

[Gerrit91]

I also added signing keyless now with a Google service account. So verification can look either like this:

❯ cosign verify ghcr.io/metal-stack/oci-mirror:sbom-and-cosign --certificate-oidc-issuer https://accounts.google.com --certificate-identity keyless@metal-stack.iam.gserviceaccount.com

Verification for ghcr.io/metal-stack/oci-mirror:sbom-and-cosign --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

Or like that:

❯ cosign verify ghcr.io/metal-stack/oci-mirror:sbom-and-cosign --key cosign.pub

Verification for ghcr.io/metal-stack/oci-mirror:sbom-and-cosign --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[majst01]

IMHO we should not depend on a google account/service for signing.

[Gerrit91]

It has the advantage that you don't need to distribute the public key somehow (like single line for verification without putting secrets somewhere in advance).

It's also an option just to offer both?

With either of these approaches we depend on the Sigstore backends like tuf-repo-cdn.sigstore.dev, Fulcio and whatever, so for offline or air-gapped environments, the current root certs need to be pulled through cosign initialize before you can verify.