Repository navigation
[Feature Request]: support signing container images with cosign #269
Description
Abstract
Cosign is a tool that supports container Signing, Verification, and Storage in an OCI registry. Cosign is created and maintained by the Sigstore community. Cosign aims to make signatures invisible infrastructure.
Motivation
To secure software supply chain is a very hot topic these days, and signing&verifying container images are the most important part of this IMHO. We have several options to use while signing&verifying container images but cosign is the most stable and popular in this area. So, if we bring this functionality to the Docker Buildx tool, we can sign container images right after we built because there's a slight time window in which it could have tampered.
Design
Again IMHO, the perfect fit with cosign and Docker Buildx is the bake command, and we thought that we can add another section for getting the details of signing such as private key, password, etc like the following:
target "sign" {
privateKey = "./cosign.key"
password = "$COSIGN_PASSWORD"
}References
cc: @Dentrax @erkanzileli
Activity
crazy-max commentedon Sep 27, 2021
cc @justincormack
jauderho commentedon Jan 28, 2022
I would add that it might be nice to have keyless cosign support wherever possible (for example using the GitHub OIDC token).
In the meantime, I've been testing keyless cosign and SBOM functionality in a post build-and-push step and think that it kinda works. See https://github.com/jauderho/dockerfiles/blob/main/.github/workflows/age.yml
What the workflow does is:
These are then verified via the verification step and this workflow now completes successfully.
However, what I've discovered is that by doing so is that the registry gets additional tags that shields.io is not able to correctly parse resulting in a
invalid response databadge. See Docker Hub: https://hub.docker.com/r/jauderho/age/tagsThis results in shields.io output that looks like this:
Code:
I'll open an issue on https://github.com/badges/shields/ but my ask is if there should be a "correct" way of naming and storing these sidecar artifacts on the registries as part of the buildout for the signing functionality for docker?
Or should the registries have functionality to store and display sidecar items?
dlorenc commentedon Feb 1, 2022
Hey, cosign maintainer here!
Yes, this is an unfortunate side effect of the way cosign does backwards-references (from signature to container image) in a registry, explained here: https://github.com/sigstore/cosign#storage-specification
The naming convention isn't a standard by any means, but it is documented as a "specification" that we intend to keep stable for interoperability: https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md
Some registries are choosing to add some special behavior for these in their UI's, given the prevalence of cosign signatures.
There's a parallel effort to improve the OCI specifications themselves, dating back to about March 2021. You can follow that progress here now: https://github.com/opencontainers/wg-reference-types. We intend to adopt this specification in cosign as soon as it is approved into the OCI specification and widely implemented!
jauderho commentedon Feb 2, 2022
@dlorenc
Thanks for weighing in.
A few questions:
Since this thread is to track development of signing support within the docker build and push action, I do not want to further distract from that topic and will update my comments here instead: jauderho/dockerfiles#149
Dentrax commentedon Feb 21, 2022
Kindly ping here. 🤞 Dropping some implementation proposal here: docker/cli#3283
Waiting for your reviews. How can we give a hand on this?
developer-guy commentedon Dec 5, 2022
kindly ping here 🙈
mgreau commentedon Mar 1, 2023
Is it planned as a first step to support the
.sigfiles on the DockerHub UI (maybe just hide these tags)?thanks