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

iamsamirzon commented 2 years ago

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.

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 commented 2 years ago

Self-assigned this issue to @shizhMSFT.

SteveLasker commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

iamsamirzon commented 2 years ago

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 commented 2 years ago

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

yizha1 commented 1 year ago

I see different combinations here:

No.	Signing Key	Artifact	Signature	Milestone
1	Local	Local	Local
2	Local	Remote	Remote	RC.1 (self-signed certificate for testing/demo/getting started)
3	Remote	Local	Local
4	Remote	Remote	Remote	RC.1

Local means the subject is stored in a local storage
Remote means the subject is stored in a remote storage (like registry)

I suggest we move task #44 out of the scope of this user story, which means this user story focuses on signing/verifying local artifacts/signatures. There is a roadmap issue #31 for local key, and we can track task#44 there.

@dtzar @shizhMSFT @iamsamirzon

SteveLasker commented 1 year ago

No. 2 works today, for getting started purposes, and could be supported in RC.1 No. 1 and No. 3 could be done later, although I'm hearing concerns about refactoring that would imply breaking changes to notation-go.

Can we agree to get No. 2 and No. 4 out, then add the others?

iamsamirzon commented 1 year ago

For #2, how do we make it clear that it is not recommended for production, and is only for demo/testing purpose. Will adding Warnings be enough? Should we still add a way to encrypt the key Vs keeping it in plain text?

dtzar commented 1 year ago

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 commented 1 year ago

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

iamsamirzon commented 1 year ago

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

yizha1 commented 1 year ago

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

yizha1 commented 1 year ago

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

yizha1 commented 1 year ago

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

notaryproject / roadmap

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