Project Lightning Talk: Blocking Vulnerable Workloads Out (And Catching What Got In) - Alessio Greggi, Maintainer

by Alessio Greggi

Day 2 · Elicium 2 · Project Lightning Talk · 5 min · 3 min read

Containers & Orchestration

TL;DR

KubeWarden and SBOM Scanner combine to block vulnerable container workloads at Kubernetes admission time. SBOM Scanner uses Trivy to scan registry images and writes VulnerabilityReport CRDs. The new image CV policy reads those reports and rejects deployments that exceed configured CVE thresholds. Set critical to zero and no image with a critical vulnerability gets admitted. The policy is context-aware, configurable per severity level, and handles missing reports with a fallback flag.

KubeWarden: a Language-Agnostic Policy Engine

▶ Watch (0:03)

KubeWarden is a universal policy engine for Kubernetes. Write policies in Go, Rust, TypeScript, or any language with a KubeWarden SDK. Each policy compiles to a WebAssembly binary packaged as an OCI artifact and pushed to a registry. That single artifact is what KubeWarden loads at enforcement time. Deploying a new policy means pushing the OCI artifact to your registry and pointing a ClusterAdmissionPolicy at it using the module attribute.

SBOM Scanner: Continuous Vulnerability Reporting

▶ Watch (1:11)

SBOM Scanner is a new KubeWarden component built around SBOM-centric security scanning. It uses Trivy under the hood, with plans to add other scanners so vulnerability reports aggregate findings from multiple tools. Point it at a registry using the Registry CRD, optionally apply image filters, and it produces a VulnerabilityReport CRD for each scanned image. Those CRDs become the data source that admission policies read at workload deployment time.

Image CV Policy: Blocking at Admission Time

▶ Watch (2:35)

The image CV policy enforces a maximum CVE count before a workload is admitted to the cluster. It is a context-aware policy: it reads the VulnerabilityReport CRD produced by SBOM Scanner and checks the counts against configured thresholds. Set the policy to protect mode and specify limits per severity level. In the demo, critical is set to zero, so any image carrying a critical CVE gets blocked when the resource is applied.

Admission Flow and the Missing-Report Fallback

▶ Watch (4:07)

The policy has a configurable fallback for missing reports. Setting ignore_missing_vulnerability_report to true lets the workload through if no report exists for that image. Leave it false and the admission is blocked. The full runtime flow: SBOM Scanner scans the configured registries, writes VulnerabilityReport CRDs, then at admission time KubeWarden reads the image CV policy, checks the matching report, and admits or rejects based on the severity counts you set.

Notable Quotes

We are actually using Trivy under the hood but we plan to extend the support Alessio Greggi · ▶ 1:23

And the policy is the image CV policy. Alessio Greggi · ▶ 2:35

Key Takeaways

KubeWarden policies compile to WebAssembly OCI artifacts, written in Go, Rust, TypeScript, or any supported language.
SBOM Scanner uses Trivy to scan registry images and produces VulnerabilityReport CRDs for each image found.
The image CV policy blocks deployments that exceed configured per-severity CVE thresholds at admission time.
Set ignore_missing_vulnerability_report to true to allow workloads through when no scan report exists yet.

About the Speaker(s)

Alessio Greggi is a Software Engineer at SUSE working with Kubernetes and security. He has been engaged with open source and community since high school. Outside of engineering, Alessio enjoys reading books and long walks.

Filed under

Containers & Orchestration