deislabs/ratify

Handle verification of manifest index

mnltejaswini opened this issue · 7 comments

mnltejaswini commented

When the subject manifest is an index, how do we identify which manifest has to be validated? Ratify has a tag to digest resolver, and if it resolves to a manifest list, this issue is to identify approaches to handle those scenarios.

sajayantony commented

Indexes can have signatures but not sure how valuable that would be. Should we atleast address that the Ratify should fail for index deployments as a first step or just audit warn?

SteveLasker commented

We didn't explicitly call this out in the ORAS Artifacts spec or Notary v2, but a signature of an index, is a signature of the index, not the redirected content.
The check should actually be done on the manifest of the image (artifact) that would actually get pulled.
If verified on a linux box, notation would validate the signature on the linux manifest.
If the index and platform-specific manifest are signed, great. If the index isn't signed, but the platform manifest is signed, should it fail as the index wasn't signed with an approved signature?
I'd suggest we actually ignore the signature on the index at this point as it's not really clear how that would be handled.

dtzar commented

This is very important to fix/enhance because multi-arch manifests will possibly fail to verify.

akashsinghal commented

I verified that ratify does function correctly when provided a reference to an OCI index with a signature attached to the Index.
Steps to Test:

  1. oras copy registry.hub.docker.com/library/redis:latest artifactstest.azurecr.io/ratify/redis:oci
  2. notation sign artifactstest.azurecr.io/ratify/redis:oci
  3. Inside a ratify enabled k8s cluster: kubectl run demo --image=artifactstest.azurecr.io/ratify/redis:oci -n demo
dtzar commented

@akashsinghal - How about you document this somewhere in here, link to this issue, and close this issue out?https://github.com/deislabs/ratify/blob/main/docs/README.md