ZEP-0038: Image Signature Verification

[Racer159]

• One-line PR description: Provide image signature verification support to Zarf directly so that image signatures can be validated before hitting a validating webhook implementation in cluster and feedback can be gathered sooner.

• Issue link: Image Signature Verification #38

• Other comments:

[AustinAbro321]

Awesome job, a nit and a clarifying question

[AustinAbro321]

Would we accept every option to verify an image that's under cosign verify -h

[Racer159]

yes I think so - there are a decent number of them but it would likely be clearer/cleaner to have a 1-1 mapping (not sure what the library code looks like for that but hopefully there would be a way to just pull those opts straight from cosign)

[brandtkeller]

Appreciative of this feature - as you allude to - it begins to both challenge and strengthen the stance of supply chain security at different stages in a package lifecycle. The create stage being arguably the most important for detecting security violations before the artifact can ever enter the operating environment.

Zarf is positioned well to continue strengthening this pattern.

[brandtkeller]

Is there any advantage to decoupling the higher-level workflow - signature verification - from the structure in configuration - cosignOpts ?

Said another way - do we think there is any evidence to support a generic configuration that can implement cosign today - but some other practices in the future? Or is coupling in this fashion provide the project with the ability to deprecate and pivot whole structures as needed?

[Racer159]

I think keeping it separate helps allows Zarf to respond to upstream changes more discretely - in the past cosign deprecated sget support which Zarf had supported natively in its code - because that was relatively tightly integrated it became more work to deprecate and remove fully - mapping the cosign opts in directly would allow them to change and explicitly calling out cosign would allow opts for other libraries to be added alongside.

I did make a change though for this to be cosignVerifyOpts though since these options would be specific to cosign verification. this structure could be broken out in a different way though potentially as something like:

package:
  create:
    imageVerification:
      cosignOpts:

[AustinAbro321]

I like cosginVerifyOpts better than cosignOpts.

I agree we should explicitly include the name cosign here as there will be lots of options available to users and keeping things aligned to cosign verify -h will help user discovery.

Changes the structure to include imageVerification is an interesting idea. @brandtkeller Do you have examples in mind of another tool that validates images using a method that cosign doesn't? Either way making the structure more generic could be good for future proofing.

[brandtkeller]

For posterity - I believe the addition of imageVerification in the structure captures the delineation between other areas of the package lifecycle where cosign options may be used or exposed. This could be the difference between options used for images and other options used for the package more broadly.

Doing so then also enables other options to be exposed that may be used by other libraries as mentioned.

[Racer159]

updated it to that field name instead

[AustinAbro321]

We should record in the build data of the package which images were verified. Not sure if we'd also want to include the cosign verification method