Sign Kyverno images and generate SBOM

[JimBugwadia]

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

Kyverno images are not signed and there is no bill of materials available.

Describe the solution you'd like

For verification of Kyverno images, they should be signed. A SBOM should also be supplied.

Additional context

Here is an example: https://schemahero.io/docs/installing/kubectl/#verifying-the-image-authenticity

[JimBugwadia]

Example and good discussion on best practices at: buildpacks/lifecycle#683.

[ShubhamPalriwala]

/assign ShubhamPalriwala

[ShubhamPalriwala]

I'm reading about Cosign, and as far as I could understand, to sign our images using cosign, we sign the SHA of the image that is returned when we push this image to Dockerhub.

I'm trying to find if we are publishing our recent images anywhere apart from GitHub Releases. On the Nirmata Dockerhub, the recent-most Kyverno image I found was pushed 10 months ago.

Is there any other way to go about this, or do you have a different idea regarding this @JimBugwadia?

[JimBugwadia]

Kyverno images are stored in GHCR (GitHub Container Registry).

To sign the image use "cosign sign ghcr.io/kyverno/kyverno:$tag" and provide the private key.

[JimBugwadia]

GoReleaser has also added signing support:

https://goreleaser.com/customization/sign/

[ShubhamPalriwala]

This $tag looks different from the tag we get when we do git describe --always. Is there a way to get this tag?

A workaround that I can think of right now is first building the image and then signing the kyverno/kyverno:latest image!
Is this valid?

[JimBugwadia]

@ShubhamPalriwala see: https://github.com/kyverno/kyverno/blob/main/Makefile#L16 for how the tag is built:

GIT_VERSION := $(shell git describe --match "v[0-9]*")
...
IMAGE_TAG?=$(GIT_VERSION)

[JimBugwadia]

Here's an example of using Cosign in a GitHub action:

https://github.com/oliviergaumond/cosign-demo/blob/main/.github/workflows/main.yml

[ShubhamPalriwala]

Thank you for the resources! I have implemented both the functionalities i.e. signing images and generating SBOMs.

So to confirm, we will be signing our images every time a commit is pushed on the main branch, i.e. adding the feature in image.yaml.

And regarding the generation of an SBOM, should it also be done after every commit to the main branch? Or after every release in release.yaml?

[JimBugwadia]

Not sure. What do you suggest?

[ShubhamPalriwala]

Regarding the signing of images, let's sign on each push as we already create images and would make it easy for a user to verify any image that is built.
Yaml used: image.yaml

Now, regarding the SBOM, generating an SBOM on every push on a branch might be redundant. For the majority of the time, significant changes will be made in a version release, hence generating an SBOM only when releasing a new version would make sense.
Yaml used: release.yaml

[ShubhamPalriwala]

@JimBugwadia So I had a look and analysed the SBOMs that were generated, 1 each for

• pre-kyverno,
• kyverno-cli,
• kyverno.

All of them were exactly the same. This can be verified over here on my fork as I uploaded the artifacts. Hence, just generating one SBOM for the kyverno release and a SHA for it should be enough.

I would like to proceed ahead with this final configuration:
For every build:

• each image i.e pre-kyverno,kverno,kyverno-cli will be signed and a SHA will be uploaded along each one of with them.
  This will take place in image.yaml
  Proof of Concept: kyverno, kyverno-cli, pre-kyverno

For every release:

• each image i.e pre-kyverno,kverno,kyverno-cli will be signed and a SHA will be uploaded along each one of with them.
• An SBOM and a SHA for the corresponding SBOM will be generated and uploaded as an artifact with the action.
  This will take place in release.yaml
  Proof of Concept: Action

There's just one bit of doubt from my end, when we release a new Kyverno version, only the release.yaml runs right? Because if the image.yaml also runs with it, we would get an extra signature in the release however the user would still be able to verify the image.

Proof for all the three image validations:

Let me know if I can go ahead and open a PR for this and a documentation PR too as discussed.

[JimBugwadia]

Hi @ShubhamPalriwala this looks good overall. Please proceed.

One clarification, when you say SHA do you mean the Cosign signature?

[ShubhamPalriwala]

So apparently, Cosign recently introduced a feature where one can directly download the associated SBOM and before downloading cosign verified the image so it does not generate a separate SHA for it, it just uploads the SBOM.
You can have a look at it here

Will now be raising a PR for the same!

[JimBugwadia]

@ShubhamPalriwala - that sounds interesting, let's try it out to understand how it extends the basic sign and verify flow.

A Cosign signature uses SHA as detailed here:

https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md

https://blog.sigstore.dev/cosign-image-signatures-77bab238a93