## Understanding Runtime-Level Supply Chain Verification in Kubernetes
In modern Kubernetes environments, securing the container supply chain is critical. Traditionally, tools like Kyverno, OPA Gatekeeper, and Sigstore Policy Controller operate at the Kubernetes API layer, using admission webhooks to validate pods before they are created. While effective, this approach has notable limitations—misconfigured namespace selectors, webhook outages, and static pod management can all bypass these safeguards.
The **Supply Chain NRI Plugin** addresses these gaps by moving verification down to the container runtime level. Supported by both **CRI-O** (1.28+) and **containerd** (1.7+, enabled by default in 2.0), the Node Resource Interface (NRI) allows plugins to hook into container lifecycle events. The Supply Chain NRI Plugin uses the `CreateContainer` hook to enforce policy **synchronously**, ensuring that every container—regardless of how it was scheduled—must pass verification before starting.
—
## Key Benefits of Runtime-Level Verification
### Defense in Depth
Admission webhooks are a necessary first line of defense, but they are not sufficient. Static pods, direct kubelet access, and webhook misconfigurations create security gaps. Runtime-level verification ensures that **no container can start without passing policy checks**, closing these loopholes.
### Resilience and Availability
Unlike admission webhooks, which can cause cluster-wide lockups when failing closed, NRI-based verification applies policy consistently without creating deadlock scenarios. It also benefits from caching and parallel checks, reducing latency and registry load.
### Comprehensive Attestation Verification
The plugin validates three critical attestation types:
– **SLSA Provenance**: Verifies build integrity, builder identity, and source origin.
– **VEX (Vulnerability Exploitability eXchange)**: Determines whether known vulnerabilities are exploitable.
– **VSA (Verification Summary Attestation)**: Allows trusted external verifiers to short-circuit full checks for improved scalability.
All checks are cryptographically verified using `sigstore-go`, supporting both keyless (OIDC) and key-based authentication.
—
## How It Works
When a container is created, the runtime calls the plugin’s `CreateContainer` hook. The plugin then:
1. Extracts the image reference and digest from runtime annotations.
2. Fetches supply chain attestations from the OCI registry.
3. Validates attestations against per-namespace policy rules.
4. Allows or blocks container startup based on policy outcome.
This workflow runs synchronously, meaning containers cannot start unless verification passes—even if they were pulled hours earlier without prior attestation checks.
—
## Configuration and Deployment
The plugin separates **operational settings** (cache TTL, timeouts, metrics) from **security policy** (trusted issuers, sources, verification rules), allowing different teams to manage them independently. Policies are defined as JSON files per Kubernetes namespace, with inheritance and override capabilities.
It deploys as:
– A **Kubernetes DaemonSet** with hardened security profiles.
– A **systemd service** for non-Kubernetes environments.
– A **pre-installed NRI plugin** for immutable node images.
The plugin uses standard Docker credential chains, integrates with Prometheus for monitoring, and supports hot-reloading without pod restarts.
—
## FAQ
### What is the Supply Chain NRI Plugin?
It is an NRI plugin that performs container image verification at the runtime level, ensuring every container started by CRI-O or containerd complies with defined supply chain policies.
### Which container runtimes does it support?
It supports **CRI-O 1.28+** and **containerd 1.7+**, and works with both CRI implementations.
### What attestation types does it verify?
It verifies **SLSA provenance**, **VEX documents**, and **VSA (Verification Summary Attestations)**.
### Can it be used outside Kubernetes?
Yes, it can run as a systemd service or directly on Linux hosts.
### What happens during a registry outage?
Behavior is configurable: by default, it logs a warning and allows the container (fail-open). This can be changed to deny mode for stricter security.
### Does it replace admission webhooks?
No. It complements admission webhooks by providing a second, runtime-level enforcement layer that cannot be bypassed by API misconfigurations or static pods.
### How are policies managed?
Policies are defined as JSON files per namespace, stored in a configurable directory, and can be updated dynamically without pod restarts.
—
## Conclusion
Runtime-level supply chain verification represents a significant step forward in Kubernetes security. By enforcing policy at the container runtime, the Supply Chain NRI Plugin eliminates entire classes of bypass risks inherent in API-layer webhooks. It provides deep defense-in-depth, strong attestation validation, and flexible deployment options.
For teams serious about supply chain security—especially in regulated or high-risk environments—moving verification to the runtime is not just an enhancement, it is a necessity. As the ecosystem continues to evolve, expect broader attestation support, improved air-gapped operation, and tighter integration with Kubernetes upstream projects.
To explore the plugin further, review the policies, test with the `–verify-image` flag, and examine how runtime-level verification fits into your broader defense-in-depth strategy.
