Support plugin distribution via OCI Artifacts

[noelbundick-msft]

The problem/background

Users that want to use plugins that are not shipped with the Ratify container image currently have to get creative to distribute those plugins, particularly in Kubernetes. Some options my team and I have explored, all of which are nontrivial hassle to folks who just want to use a plugin:

• Build your own Ratify image: copy in your own plugin, then use it manually or in the Helm values
  • This is high friction. At minimum I have to docker build with Ratify as a base. At worst, I am compiling all of Ratify myself
  • Note: currently, versions must match exactly with the crd image, unless you want to build that on your own as well
• Build your own Helm chart: modify it to include an initContainer + volume mount (or some other means) to get your plugin downloaded on startup
  • This is a slight improvement, but still means I'm relying on resources not built & validated by the upstream Ratify project
  • The initContainer solution works as long as all plugins are guaranteed to be known at startup. With CRD's driving configuration, this is guaranteed not to be the case
• Use Helm postRender + Kustomize to add the initContainer
  • This is actually a large improvement - I can rely on upstream bits
  • The "must have plugin binaries at startup" problem remains
  • It's definitely in the "advanced Helm techniques" category - more than a typical user should be forced to understand just to use a plugin

Describe the solution you'd like

As discussed on the 2022-12-13 community call, I would like Ratify to be able to pull down and execute plugins from an OCI registry based on a user-provided source property

For example, a CRD for an imaginary plugin named noel would look like this:

apiVersion: config.ratify.deislabs.io/v1alpha1
kind: Verifier
metadata:
  name: verifier-noel
spec:
  name: noel
  artifactTypes: vnd.noel.custom
  parameters: 
    source: noelregistry.azurecr.io/verifier-noel:v1

That would trigger Ratify to

• authenticate to the noelregistry.azurecr.io registry
• pull down the noelregistry.azurecr.io/verifier-noel:v1 OCI artifact
• place it into the plugin bin dir to match the spec.name, ex: ~/.ratify/plugins/noel
• mark that file as executable

Then later, when a verify request is sent from Gatekeeper/CLI, Ratify would operate normally as it does today - resolving the plugin path, and executing it using the same code that works today.

Anything else you would like to add:

I have a PoC here: main...cse-labs:ratify:plugins-as-oci-artifacts

Assuming we move forward, I would also propose some refactoring of ORAS usage, particularly around auth providers - effectively pulling those up a level as a shared component rather than embedded strictly as part of the oras store. So that plugins can be downloaded with the same auth options that oras store successfully uses today.

Caching is also up for discussion, but plugin registration & download should happen only at startup or when Stores/Verifier CRDs are updated, so I anticipate that to have minimal impact

Usage would look something like:

# Step 1: get a plugin binary
curl -L https://github.com/noelbundick-msft/ratify-verifier-plugin/releases/download/v1.0.0/noel-linux-amd64 -o ./noel

# Step 2: push it to my OCI registry
oras push noelregistry.azurecr.io/verifier-noel:v1 ./noel

# Step 3: register a Verifier via CRD (see above)

# Step 4: do something that invokes Ratify and has a referrer with the targeted artifactType, ex:
kubectl run demo --image=noelregistry.azurecr.io/test/my-image:v1

I'm opening up this issue for further discussion & refinement before potentially submitting a PR to have this included, ideally in the RC1 timeframe

Also related to #468

cc @sajayantony

[noelbundick-msft]

Added behind the RATIFY_DYNAMIC_PLUGINS feature flag in #519

Usage information: https://github.com/deislabs/ratify/blob/main/docs/reference/dynamic-plugins.md