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

@developer-guy

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

@crazy-max

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

@justincormack

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

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?

Let me link this to docker/roadmap#269

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.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

developer-guy commented on Sep 10, 2021

thaJeztah commented on Sep 10, 2021

Dentrax commented on Sep 27, 2021

thaJeztah commented on Sep 28, 2021

justincormack commented on Feb 28, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions