[Feature Request]: support signing container images with cosign

[developer-guy]

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

• Sigstore
• Cosign
• Buildx Bake

cc: @Dentrax @erkanzileli

[crazy-max]

cc @justincormack

[jauderho]

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:

• Build and push the container image
• Sign the digest (vs. a tag) using keyless cosign
• Use syft to generate SBOM
• cosign attestation of the SBOM

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 data badge. See Docker Hub: https://hub.docker.com/r/jauderho/age/tags

This results in shields.io output that looks like this:

Code:

[![Build Status](https://github.com/jauderho/dockerfiles/workflows/age/badge.svg)](https://github.com/jauderho/dockerfiles/actions)
[![Version](https://img.shields.io/docker/v/jauderho/age/latest)](https://github.com/FiloSottile/age)
[![Docker Pulls](https://img.shields.io/docker/pulls/jauderho/age)](https://hub.docker.com/r/jauderho/age/)
[![Image Size](https://img.shields.io/docker/image-size/jauderho/age/latest)](https://hub.docker.com/r/jauderho/age/)

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]

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!

[jauderho]

@dlorenc

Thanks for weighing in.

A few questions:

• Which registries are accounting for this special behavior? I'd like to take a look
• I see the proposal for parsing and accounting for the associated .sig. Will .att attestations be handled the same way?
• I just saw that there is an ability to specify an alternate repo (https://github.com/sigstore/cosign#registry-details) Is that going to be the preferred way going forward?

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]

Kindly ping here. 🤞 Dropping some implementation proposal here: docker/cli#3283

Waiting for your reviews. How can we give a hand on this?