[Feature Request] add cosign for verifying signature while pulling image

[Dentrax]

Abstract
What we propose is that we can support custom content trust verifiers into Docker besides Notary such as cosign. Actually, the idea is coming from a discussion on sigstore slack channel by @developer-guy.

Motivation

cosign, is a lightweight, container signing, verification, and storage in an OCI registry. We should avoid unnecessary image pulling before checking whether the image is signed.

Proposal

Docker has support for Notary in its own CLI, the trust command and there is a special variable called

$ export DOCKER_CONTENT_TRUST=1

...which helps users to ensure that the image that they pull has a valid signature on the Notary server. Would it makes sense if we add the same functionality to the docker daemon for cosign? That said, this way we can avoid verifying the image after downloading it, we would have done it while downloading the image, do we have a plan for that.

$ docker image pull developer-guy/alpine:3.12
$ cosign verify -key cosign.pub developer-guy/alpine:3.12  # check if signed

Instead of this one, we would do these several ways:

Solution 1: cosign specific

$ export DOCKER_CONTENT_TRUST_COSIGN_ENABLED=1
$ docker image pull developer-guy/alpine:3.12  # check if signed

• How will Docker decide to which content trust verifier be used?

Solution 2: support interchangeable container signers: users decide the trust verifier

$ export DOCKER_CONTENT_TRUST_VERIFIER=notary
$ export DOCKER_CONTENT_TRUST_VERIFIER=cosign
$ export DOCKER_CONTENT_TRUST_VERIFIER=my-custom-signer

Caveats:

By implementing this way, we may have to determine a custom trust verifier interface API. An interface that enables Docker to use a wide variety of container signers & verifiers.

cc: @dlorenc @lukehinds

[developer-guy]

would you like to help us with this issue folks, @crazy-max @thaJeztah? 🤝😋

[thaJeztah]

Let me ping @justincormack, who may have ideas / thoughts on this.

[Dentrax]

Currently, image/trust.go only supports Notary client. To support different trust verifier clients (i.e., notary, cosign, etc.), should we create a new specification or interface for this?

type TrustVerifier interface {
	Name() string
        TrustedPush() error
	PushTrustedReference() error
	TrustedReference() (reference.Canonical, error)
	TagTrusted() error
}

At the directory ./cli/command/image/ we can create a new folder called trust-providers like the following:

.
|_ notary
    |_ provider.go
|_ cosign
    |_ provider.go
|_ ...

Implementing the struct into provider.go will quite easy:

type CosignProvider struct{}

func (p CosignProvider) Name() string { return "Cosign" }

func (p CosignProvider) TrustedPush() error {
        // operations to do ...
	return nil
}

func (p CosignProvider) PushTrustedReference() error {
        // operations to do ...
	return nil
}

func (p CosignProvider) TrustedReference() (reference.Canonical, error) {
        // operations to do ...
	return nil, nil
}

func (p CosignProvider) TagTrusted() error {
        // operations to do ...
	return nil
}

providers := []TrustVerifier{trust.CosignProvider(), trust.NotaryProvider()}
// decide the which provider being used
// pass provider from the cli flag?

Any thoughts?

[thaJeztah]

Let me link this to docker/roadmap#269

[justincormack]

The DOCKER_CONTENT_TRUST=1 "API" has not been very effective. The problem with it is that it is global, but with most images being unsigned this doesn't work well. We need a better interface that supports a gradual change in the ecosystem moving to signing.