Add support for sigstore/cosign

[sambhav]

https://github.com/sigstore/cosign is a project from sigstore. Instead of relying of a separate service/notary, it can directly push signatures to the OCI registry signed using a key. This might be a lightweight alt. to image signing via notary.

[matthewmcnew]

Hi @samj1912, In some excellent serendipity, I was just chatting with some of my colleges at VMware about this.

cc-ing @stormqueen1990 @rszumlakowski

[rszumlakowski]

Heya @matthewmcnew. @stormqueen1990 and our team were working on a RFC for Cosign integration with kpack today. We will probably send it your way tomorrow.

[rszumlakowski]

Hi @samj1912 . Can you please describe your use case? I'd like to make sure that the RFC that we are putting together covers your Cosign use case.

[sambhav]

Hi @rszumlakowski my main use case is verifying that the images came from a specific kpack build cluster.

I am hoping that the controller can be provided with the cosign private key that only the controller has access to (the users who are in other namespace using the Image resource should not be able to access this private key). The idea being that during kpack image build process, after the image is built and published the controller can then generate the signature with the following claims and push it to the registry -

• cluster builder used
• the buildpacks involved in the build process
• the stack images
• build time

This is to verify that the images created by users came from a specific cluster and cluster builder that can be verified during runtime via an admission controller like https://github.com/dlorenc/cosigned

[stormqueen1990]

Hi @samj1912!

Do you think having a Secret to hold the private key provides enough isolation for your use case? Or have you considered a different method for providing kpack with the private key?

Thanks in advance!

[sambhav]

A secret would be good enough that the controller can refer to if needed. The main issue here would be having this secret in the kpack namespace which normal users can't access/use to create the signatures for images in user namespaces. I can see two ways of doing this -

1. Have the controller spin up a pod in the kpack namespace that can fetch the image created in the user namespace, sign it and then create a pod in the user namespace and use the user imagepull secret to push the signature out.
2. Have the controller itself fetch the image pull secret used by the user (this should be possible since the controller can currently access all secrets in all namespaces) , create a pod in the kpack namespace that can pull the image, sign it and then push it out all in the kpack namespace. The latter might be tricky given cross-namespace secrets.

[matthewmcnew]

(the users who are in other namespace using the Image resource should not be able to access this private key)

Can this be accomplished with kubernetes RBAC?

[sambhav]

(the users who are in other namespace using the Image resource should not be able to access this private key)

Can this be accomplished with kubernetes RBAC?

It definitely could be. The key difference is that instead of this secret being in the image spec, it has to be on the controller side instead.