Validate cosign signatures if included in `images`

[Racer159]

Is your feature request related to a problem? Please describe.

As Ezra I want to validate cosign signatures on zarf package create so that I can have confidence that they will work correctly before the package goes to the air gap.

Describe the solution you'd like

• Given I have a package with cosign signatures defined under images
• When Zarf pulls the signatures and the images to which they relate
• Then Zarf validates the signatures against the images

Describe alternatives you've considered

We could have a separate process for this (and this will slow down create) but since it will only run when cosign signatures are defined it should be a fine tradeoff since people can opt into the slowdown if they need / want to and if they do it will save them time in the long run since it would be costly to bring an invalid package to the airgap.

Additional context

#475

[mjnagel]

validate cosign signatures on zarf package create so that I can have confidence that they will work correctly

Want to call out this is more than just "confidence they will work correctly" in the broad sense, but also confidence the image is what I expected (i.e. isn't some maliciously published image, it was published by the build system I expected). There's some valuable supply chain considerations there.

Given I have a package with cosign signatures defined under images

While I think this is a good qualifier for a first pass, it would honestly be great if there were also a way to opt-in to signature validation even if I don't put signatures in images. It shouldn't be significantly more challenging since zarf already has code to find signatures, and in some cases I might just want signatures to be validated at build time and have no need to bring them along with me in my zarf package.

Then Zarf validates the signatures against the images

Worth noting that there are a number of different validation paths with cosign - you may need to pass in a key, skip the tlog, or it might just work (keyless signatures?). Would likely mean we need an additional "config block"/args to specify some of those options, and potentially allow it per registry/repo/image.

[Racer159]

To describe use cases more, it would be nice to be able to validate the signatures of images that are pulled down by Zarf before a Zarf package is fully created to ensure that it has the images you expect before the package itself is (potentially) signed.

Generally there are two ways that images could be signed:

1. From public infrastructure:
   https://kubernetes.io/docs/tasks/administer-cluster/verify-signed-artifacts/
2. From a private/local key infrastructure:
   https://docs-ironbank.dso.mil/tutorials/cosign/

And complicating this further is the fact that Zarf could contain sets of images from different sources with different signing verification needs.

Generally, however this configuration wouldn't change much for the life of a given application (only really changing when base image infrastructure changes), so this could be collapsed into a map of cosign configuration options to registry sources (since many image sources are likely to be similar - i.e. all K8s images or all Iron Bank images will use the same verification configs). This could be implemented as a new cosignOpts option on package create like this:

package:
  create:
    cosignOpts:
      registry.dso.mil/*:
        certificate-chain: cosign-ca-bundle.pem
        cert: cosign-certificate.pem
      registry.k8s.io/*:
        certificate-identity: krel-trust@k8s-releng-prod.iam.gserviceaccount.com
        certificate-oidc-issuer: https://accounts.google.com

Which could also be like this:

zarf package create . --cosignOpts='{"registry.dso.mil/*": {"certificate-chain": "cosign-ca-bundle.pem", "cert": "cosign-certificate.pem"}, "registry.k8s.io/*": {"certificate-identity": "krel-trust@k8s-releng-prod.iam.gserviceaccount.com", "certificate-oidc-issuer": "https://accounts.google.com"}}'

Of course an operator would also be nice to have to perform validation in a cluster but when you are crossing the airgap that operator would be validating the image signatures long after the package left the development environment and having an easy way to validate this up front would be very useful.