Consider adding official support for signing and verifying container images with cosign
Context
A new project under The Linux Foundation, named sigstore, and started by Google, RedHat, and the Purdue University, aims to provide a standard and tools for signing and verifying software. Among the project tools, there is cosign, which is used to sign and verify container images (or any other images) stored in OCI registries, such as the GitLab Container Registry.
With cosign, signatures are also stored in the container registry, alongside the images they reference, which can seamlessly integrate the two while using a single store, the container registry. For more details, please see the project (sigstore) and the tool (cosign) documentation.
We had several requests to provide a way to sign and verify container images. This may apply not only to customers who want to validate the integrity of the content they publish to the registry and images published by GitLab, such as those in CNG, providing customers with a way to verify them before deployment.
Proposal
Until recently (July 28th, 2021), cosign was not considered production-ready, but this has now changed with the v1.0.0 release. So this is a good timing to evaluate it.
Cosign is currently compatible with any OCI compliant registry, which includes the GitLab Container Registry. However, we have a major registry re-architecture effort in progress that, among others, intends to make it easier to index and analyze metadata (such as signatures) and the relationship between images.
Therefore, before endorsing it and/or providing official support, and official support here means recommending it as the solution for signing and verifying images, providing documentation/examples specific to GitLab (e.g., CI workflows), and plan possible UX improvements, such as displaying signatures alongside images on the GitLab UI (and the underlying API), it is important to:
-
Validate how well cosign plays with our mid/long-term goals for the container registry and the technical compatibility;
-
Validate if it would be possible/desired to adopt it for signing and verifying official images published by GitLab, such as those in CNG;
-
Last but not least, this should also be reviewed by the GitLab Security Department.
Alternatives
Apart from cosign, we should mention Notary V2, which is an evolution from the original Notary project from Docker. It also aims to provide a way to sign and verify software stored in container registries. Still, unlike cosign, it is not complete or production-ready and requires changes to the image manifests and the registry API. These changes (to OCI standards) are unlikely to be completed and adopted by most registry providers soon.
One of the main benefits of cosign is that it complies with the existing specifications and therefore works with most registry providers today, which means less friction and quicker adoption. This is why we are looking specifically at cosign.