[User Story] - notation sign/verify Offline/Local artifacts

[iamsamirzon]

As a user, I'd like to be able to sign and verify artifacts on my local machine so that see Steve's comment. This is also important for a good CI/CD workflow.

• notation sign/verify to work with local storage notation#283
• Signature Local storage specification specifications#182
  - [ ] Spec for signing with local key #44

Related to local signing via plugin #31

Original notes:
Current implementation relies on container images already in registry; This item is to Sign before push; and then push image, signature, and tag up to the registry;

https://hackmd.io/D6l6ckAwT8CqAvQYoDKR-Q

[shizhMSFT]

Self-assigned this issue to @shizhMSFT.

[SteveLasker]

@SteveLasker to capture details for:

• full offline artifact and signing for pushing to an air-gapped network
• tag update scenarios, where all the artifacts are prepped (image is created) then signed, without having to push to the registry
• a TSA may not be available, or a public TSA may not be available. A private TSA may be accessible from within the VNet
• verifying the signatures
• k8s on-node verification
• on-disk layout
• dialtone scenarios, where the VM is pre-cached
• local scan, before being pushed to the registry

Add/propose some priority for local/tag update semantics

https://hackmd.io/D6l6ckAwT8CqAvQYoDKR-Q

[sudo-bmitch]

For offline signing without a registry, I'd focus on OCI Layout. That's a format formal spec that's not tied to any specific vendor, and it's also supported as an output of builders like docker buildx.

[shizhMSFT]

containerd also uses the OCI Layout, and its implementation is available at github.com/containerd/containerd/content/local.

As mentioned in the HackMD doc, manifests are stored in the content store in the OCI Layout by the containerd so that we can find out the manifest and sign it directly.

[sudo-bmitch]

Does this mean the signing node must have containerd installed and running with the image loaded? What if I only have an OCI layout that's packaged as a tar+gzip and the signing node doesn't have containerd installed?

[shizhMSFT]

Does this mean the signing node must have containerd installed and running with the image loaded?

Nope. We can have a tool to extract the gzipped tarball of the image in the OCI layout. The image manifest can be found via the index.json file. The issue becomes: Should the notation CLI integrate this tool? Any votes?

[shizhMSFT]

Precisely, an index.json in the OCI layout generated by buildx looks like

{
  "schemaVersion": 2,
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:14e07c4dd3870aeb39fc469fae3294733b15142cadfbfdef699811018da340d6",
      "size": 505,
      "annotations": {
        "io.containerd.image.name": "registry.wabbit-networks.io/net-monitor:v1",
        "org.opencontainers.image.created": "2021-11-04T09:04:26Z",
        "org.opencontainers.image.ref.name": "v1"
      }
    }
  ]
}

In this case, we can easily find the manifest for registry.wabbit-networks.io/net-monitor:v1, which is sha256:14e07c4dd3870aeb39fc469fae3294733b15142cadfbfdef699811018da340d6.

Then we can do

notation sign --local --output manifest.sig \
    --media-type application/vnd.oci.image.manifest.v1+json \
    blobs/sha256/14e07c4dd3870aeb39fc469fae3294733b15142cadfbfdef699811018da340d6

[sudo-bmitch]

I guess I'm just confused why we're referring to an implementation of the spec, rather than the spec itself. With the docker save format, that's understandable since it's a docker proprietary format without a formal spec. But if containerd and other tools are just implementing the OCI Layout spec, shouldn't we refer to that spec rather than a single vendor's implementation which that vendor could decide to change in the future? Is this group opposed to working with OCI for some reason?

[SteveLasker]

I believe @shizhMSFT is saying we are aligning around the image layout. He was using docker save as an example and something we need to think about more as we're not limiting building or signing to the docker cli.
We can change the reference to the oci spec, although this is another instance where it living under the container image runtime is up for refactoring as well. There are some constraints we should work to clarify.

Is this group opposed to working with OCI for some reason?

@sudo-bmitch, considering how much time has been spent working with OCI, what suggests the group isn't?

[SteveLasker]

With the signing plugins, this is less of a notation default policy and implementation detail of the plugin.
Suggestion to close

[iamsamirzon]

Offline signing is for signing images built locally and while those images have not yet been pushed to the registry. This is different from the plugins.

[iamsamirzon]

Moving out to alpha-3 as local signing/offline signing has dependencies on client software which needs more thought

[dtzar]

Discussed this on the community call 10/20. I think it's ok to do 2 & 4 for RC-1 and add 1/3 later.

For the warning - putting something in the release notes and perhaps a warning message when someone signs. It's not that option 2 is invalid, it's that it has a security risk/concern. This risk/security concern should be spelled out in more detail for the release IMO.

I do think we should enable 2 in a production capability post RC-1 with one of the options Roy mentions here.

[iamsamirzon]

Based on the agreement in NV2 community call on 12/5/2022, moving this out of RC-2

[iamsamirzon]

Discussed this on 12/8/2022 NV2 call. Brought the spec work in RC-2

[yizha1]

@iamsamirzon @vaninrao10 I would suggest creating a new one for implementation, and updating the title of this one by adding key word spec.

[yizha1]

Update the milestone to rc-3 based on the discussion.

[yizha1]

Move to future milestone, since more works needed after v1 release