-
Notifications
You must be signed in to change notification settings - Fork 92
spec: add spec for notation verify command #371
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
Changes from all commits
df1e729
bcc2ea4
f72b2a6
1950096
4b76dfc
c0f2d12
8735263
7ddfebd
75dd7aa
47fdd40
dc11d59
f8a0fd2
68489cb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,99 @@ | ||
| # notation verify | ||
|
|
||
| ## Description | ||
|
|
||
| Use `notation verify` command to verify signatures on an artifact. Signature verification succeeds if verification succeeds for at least one of the signatures associated with the artifact. The digest of the supplied artifact is returned upon successful verification. It is recommended that this digest reference be used to pull the artifact subsequently, as registry tags may be mutable, and a tag reference can point to a different artifact that what was verified. | ||
|
|
||
| ## Outline | ||
|
|
||
| ```text | ||
| Verify signatures associated with the artifact. | ||
|
|
||
| Usage: | ||
| notation verify [flags] <reference> | ||
|
|
||
| Flags: | ||
| -h, --help help for verify | ||
| -p, --password string Password for registry operations (default to $NOTATION_PASSWORD if not specified) | ||
| --plugin-config strings {key}={value} pairs that are passed as is to a plugin, if the verification is associated with a verification plugin, refer plugin documentation to set appropriate values | ||
| -u, --username string Username for registry operations (default to $NOTATION_USERNAME if not specified) | ||
| ``` | ||
|
|
||
yizha1 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| ## Usage | ||
|
|
||
| Pre-requisite: User needs to configure trust store and trust policy properly before using `notation verify` command. | ||
|
|
||
| ### Configure Trust Store | ||
|
|
||
| Use `notation certificate` command to configure trust stores. | ||
|
|
||
| ### Configure Trust Policy | ||
|
|
||
| Users who consume signed artifact from a registry use the trust policy to specify trusted identities which sign the artifacts, and level of signature verification to use. The trust policy is a JSON document. User needs to create a file named `trustpolicy.json` under `{NOTATION_CONFIG}`. See [Notation Directory Structure](https://github.com/notaryproject/notation/blob/main/specs/directory.md) for `{NOTATION_CONFIG}`. | ||
|
|
||
| An example of `trustpolicy.json`: | ||
|
|
||
| ```jsonc | ||
| { | ||
| "version": "1.0", | ||
| "trustPolicies": [ | ||
| { | ||
| // Policy for all artifacts, from any registry location. | ||
| "name": "wabbit-networks-images", // Name of the policy. | ||
| "registryScopes": [ "*" ], // The registry artifacts to which the policy applies. | ||
| "signatureVerification": { // The level of verification - strict, permissive, audit, skip. | ||
| "level": "strict" | ||
| }, | ||
| "trustStores": [ "ca:wabbit-networks" ], // The trust stores that contains the X.509 trusted roots. | ||
| "trustedIdentities": [ // Identities that are trusted to sign the artifact. | ||
| "x509.subject: C=US, ST=WA, L=Seattle, O=wabbit-networks.io, OU=Finance, CN=SecureBuilder" | ||
| ] | ||
| } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| In this example, only one policy is configured with the name `wabbit-networks-images`. With the value of property `registryScopes` set to `*`, this policy applies to all artifacts from any registry location. User can configure multiple trust policies for different scenarios. See [Trust Policy Schema and properties](https://github.com/notaryproject/notaryproject/blob/main/trust-store-trust-policy-specification.md#trust-policy) for details. | ||
|
|
||
| ### Verify signatures on a container image stored in a registry (Neither trust store nor trust policy is configured yet) | ||
|
|
||
| ```shell | ||
|
|
||
| # Prerequisites: Signatures are stored in a registry referencing the signed container image | ||
|
|
||
| # Configure trust store by adding a certificate file into trust store named "wabbit-network" of type "ca" | ||
| notation certificate add --type ca --store wabbit-networks wabbit-networks.crt | ||
|
|
||
| # Configure trust policy by creating a JSON document named "trustpolicy.json" under directory "{NOTATION_CONFIG}" | ||
| # Example on Linux | ||
| cat <<EOF > $HOME/.config/notation/trustpolicy.json | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is going to vary based on the user's operating system. IMO we should consider if we can get a "bare bones" cli implementation which simply writes a template similar to what's there to the user's proper directory (i.e. notation policy create -n default) and possibly opens it up or lists where it is at. (i.e. notation policy list or notation policy open (optional --name default)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will create a new issue for a discussion regarding this request.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
| { | ||
| "version": "1.0", | ||
| "trustPolicies": [ | ||
| { | ||
| "name": "wabbit-networks-images", // Name of the policy. | ||
| "registryScopes": [ "registry.wabbit-networks.io/software/net-monitor" ], // The registry artifacts to which the policy applies. | ||
| "signatureVerification": { // The level of verification - strict, permissive, audit, skip. | ||
| "level" : "strict" | ||
| }, | ||
| "trustStores": [ "ca:wabbit-networks" ], // The trust stores that contains the X.509 trusted roots. | ||
| "trustedIdentities": [ // Identities that are trusted to sign the artifact. | ||
| "x509.subject: C=US, ST=WA, L=Seattle, O=wabbit-networks.io, OU=Finance, CN=SecureBuilder" | ||
| ] | ||
| } | ||
| ] | ||
| } | ||
| EOF | ||
|
|
||
| # Verify signatures on a container image | ||
| notation verify registry.wabbit-networks.io/software/net-monitor:v1 | ||
| ``` | ||
|
|
||
| ### Verify signatures on an OCI artifact stored in a registry (Trust store and trust policy are configured properly) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is confusing as to OCI artifact versus trust * configured versus not. I'd then have a section on what the experience is like when trust store and policy is not configured. I'd imagine you wouldn't get a verification, but show some error message(s).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will create a new PR to address this comment and the error handling parts. |
||
|
|
||
| ```shell | ||
| # Prerequisites: Signatures are stored in a registry referencing the signed OCI artifact | ||
|
|
||
| # Verify signatures on an OCI artifact identified by the digest | ||
| notation verify registry.wabbit-networks.io/software/net-monitor@sha256:abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234 | ||
| ``` | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should explain here and in the sign command that < reference > support can be a tag or a digest. When with a tag, we do a default tag to digest translation and we only sign/verify the digest, not the tag itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will create a new PR to address this