What is the problem you're trying to solve

We would like to be able to verify images after a digest is resolved and before image layers are pulled, using a customizable plugin.

A verifier would be a function or RPC that takes in an ocispec.Descriptor and returns a value indicating whether the image pull should continue.

Verifying image digests is fairly easy in a plain containerd client. A client can provide a custom remotes.Resolver that verifies the resolved digest before returning from Resolve, or at the start of Fetch in the returned Fetcher. If verification fails, the custom remotes.Resolver would return an error, which would bubble up as an ordinary image pull error.

However, when operating containerd through the CRI plugin, the resolver is hard coded and not extendable (source). We would like a way to add verification functionality to the resolver without running a fork of the CRI plugin.

Describe the solution you'd like

I am proposing adding a plugin interface to the CRI, with a function along lines of the following:

Verify(resolved OCI descriptor for image manifest) -> error

In the absence of a configured plugin, the CRI would function exactly as it does today.

Ideally, this would be a gRPC plugin interface. When experimenting with containerd shared object plugins, I found that it was difficult to integrate custom code outside the containerd codebase, since --buildmode=plugin requires go.mod dependency versions and build flags to exactly match those used to build the containerd binary. I think using a gRPC plugin here would make it easier for third parties to build and release CRI verifier plugins.

Additional context

Open source projects such as Sigstore and Notary v2 are introducing new ways to sign container images. However, signing images only delivers the promised security improvements if the signatures are actually verified at runtime.

The prevailing recommendation for runtime image verification in Kubernetes is to use admission webhooks (see Sigstore's cosigned webhook and Connaisseur). However, complex admission controllers such as these can be a high maintenance single point of failure for organizations with large clusters, or many clusters. Additionally, these admission controllers sit at an unnatural place in the container image lifecycle (before a digest is resolved for the requested image tag). In order to support images without digest references, they rely on a mutating webhook to resolve a digest before a validating webhook then verifies a signature for the image digest.

The feature I'm proposing improves the verification story for container image signatures. Verification at the node level enhances the security benefits of image signature validation by minimizing the trusted compute base that handles the image digest after the signature is verified. Furthermore, by obviating the need for running high-availability admission webhooks, it reduces the operational cost of verifying image signatures.

Related to #7592 and #7654