Add RFC for cluster-wide image signing via cosign #765
Conversation
Signed-off-by: Sambhav Kothari <[email protected]>
sambhav
changed the title
sambhav
changed the title
| - Use the appropriate `docker-registry` secrets attached to the kpack controller service account to push this signed payload to an appropriate registry. | ||
| - Update the `Build` and `Image` status to reflect the output from pushing the signature. | ||
|
|
||
| This assumes that the `kpack` controller service account is configured appropriately to have the `cosign` and [`docker-registry`](https://github.com/pivotal/kpack/blob/main/docs/secrets.md#docker-registry-secrets) secrets as needed. |
There was a problem hiding this comment.
How will the controller's service account be configured and specified?
| for policy enforcement in container images. | ||
| - [Notary v1 implementation pull request](https://github.com/pivotal/kpack/pull/541). | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Could this be a completely separate kubernetes deployment that automatically signs every status.latestImage produced by kpack?
|
|
||
| - Implement a flow that generates the `cosign` signature payload for the image on the controller side based on the image digest output from the `Build`, then calculates its signature and pushes it either to the registry specified using the [to the registry specified in the `COSIGN_REPOSITORY` environment variable](#key-generation-and-storage), using the image signing credentials provided to the controller. This flow must happen after the image has been pushed to the registry. | ||
|
|
||
| - If `cosign` fails to sign an image, the build should fail and output an error message in the build log, so the operator can troubleshoot the issue. The error messages should also be added in any other places where error messages are presented. |
There was a problem hiding this comment.
If the signing is happening in the controller would it be acceptable to simply report the signing error on the build status?
|
|
||
| `kpack` will be able to determine that the user wants to sign images using `cosign` by scanning the annotations in each of the secrets. Secrets to be used by `cosign` signing should be annotated with `kpack.io/cosign-credentials`. | ||
| Optionally, the user can also annotate the secrets with the following information: | ||
| - `kpack.io/cosign.repository`: a separate registry URL to upload the generated signatures, instead of pushing the signatures collocated with the images. Adding this annotation should have the same effect as setting the `COSIGN_REPOSITORY` |
There was a problem hiding this comment.
If this is optional where will the signature be written?
|
this would be very helpful for our use case. we heavily rely on cosign at multiple stages in our software supply chain. the first signature which serves as a sort of attestation or provenance of where and by what the image was built is done via the kpack cosign integration and having it at a cluster wide level would be extremely helpful and would make management of signing keys and secrets much easier. we use cosign throughout our supply chain for example after scanning, after sandboxing the images etc. which serve as the final approval of an image to be run but having this signature from kpack is key to us as it is a very simple and effective way to verify the source of the image. |
Signed-off-by: Sambhav Kothari [email protected]
cc: @matthewmcnew @dlorenc @ncdc @stormqueen1990
Readable