-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: support signing container images with cosign #269
Comments
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 This 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? |
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! |
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 |
Kindly ping here. 🤞 Dropping some implementation proposal here: docker/cli#3283 Waiting for your reviews. How can we give a hand on this? |
kindly ping here 🙈 |
Is it planned as a first step to support the thanks |
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
andDocker Buildx
is thebake
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:References
cc: @Dentrax @erkanzileli
The text was updated successfully, but these errors were encountered: