-
Notifications
You must be signed in to change notification settings - Fork 205
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
Requirements: Artifact Signing #70
Comments
An important design constraint is whether additional sigs can be added without changing the root image digest (i.e. what the mutable tag points to). If bumping tags is ok, sigs can live in CAS. If tags cannot be bumped, tags must live outside of CAS. |
Previous discussion in opencontainers/image-spec#22, opencontainers/image-spec#176, and opencontainers/image-spec#400. |
@wking Can you add more details to your note? When you say "can live in CAS," do you just mean within the manifest like in schema 1? |
Manifests get pulled by reference, and references can be names or digest, so they're content addressable, but also tag-addressable (presumably to make space for HTTP content-negotiation for compat with clients who don't understand new media types). But now we have indexes, which are kind of tiptoeing into in-CAS content negotiation. By "in CAS" I mean "is pushed as an opaque blob and retrieved by digest", like we currently use for layers. It would be nice to be able to push whatever types you want (including signature objects) into the CAS blob store, and then push an array of descriptors as the mutable tag. Clients would request the tag by name, and the server would select an entry based on content negotiation |
i think this issue can be closed. This is the point of the Notary v2 discussion, and to store the signatures themselves as referenced blobs in a registry. Whether or not Notary v2 fully delivers on that is not a blocker for this distribution-spec. |
Adding links to Notary v2 efforts, and closing this issue as it's being tracked separatley: |
OCI Artifact Signing - Requirements
As containers become the common unit of deployment, users want to know the images in their private registries and their deployments are the same images that were initially published.
The OCI TOB has adopted OCI Artifacts, generalizing container images as one of many types of artifacts that may be stored in a registry. Other artifact types currently include:
The Need for a Generalized Signing Solution
This document serves as the requirements and constraints of a generalized signing solution. It focused on the scenarios and needs, and very specifically avoids any reference to other projects or implementations. As our working group forms a consensus on the requirements, the group will then transition to a spec. Existing verification & signing solutions can be compared against the requirements and spec to identify best fits.
Key Stake Holders & Contributors
As we identify the requirements and constraints, a number of key contributors will be asked to represent their requirements and constraints.
Requirements
As we begin a new design, we must ask what defines success.
Generic Artifact Support
While Docker Content Trust focused on container images, registries have evolved to now support any type of artifact. An image is just one of many artifacts. As a result, OCI has adopted OCI Artifacts
As we consider a new signing solution, we look to support any artifact to be signed, including images, Helm charts, OPA bundles, Singularity High Performance Computing images, to new, yet unknown artifacts.
Artifact Movement
Signature Movement
Registry Operator Differentiated Value
Registry operators must be able to leverage other systems within their product and service lines. Specifically, the spec must allow for:
Open Topics
The following accounts for the list of open topics that should be considered.
Parking Log / Backlog
This section accounts for any topics the working group deems deferred for current conversation.
The text was updated successfully, but these errors were encountered: