ValidatingAdmissionPolicy (VAP) is appealing, but introducing new policies to an existing Kubernetes cluster seems difficult. Before enabling enforcement, I want to understand which currently running workloads would violate a policy. Warn mode only evaluates objects when they are admitted or updated, so idle workloads can remain unnoticed. The audit action has a similar limitation and can require searching through audit logs.
One option is to use Kyverno in audit or background mode to scan existing resources, but that adds another cluster tool if Kyverno is not already in use. Are there tools that can evaluate VAP policies against existing cluster resources before deployment, preferably off-cluster? Alternatively, is there a practical way to track policy results without manually digging through audit logs?
3 Answers
Warn mode does not solve the existing-resource problem because admission is triggered by creates and updates. An idle workload that already violates the policy will not be checked until something changes it. Audit mode can record violations without blocking admission, but it has the same limitation for resources that are already sitting in the cluster. In practice, you need to export the current objects and evaluate them directly with the policy's CEL rules, or use a tool that performs that sweep for you.
One option is kubeapt, which can run VAPs against cluster resources without installing the policies first. Its validation command lets you check your own policies—or built-in policy bundles—and review likely violations before changing admission behavior. It can be useful for security audits as well as rollout planning.
For an off-cluster workflow, you can export the relevant live resources with kubectl, remove runtime-only fields, and evaluate them in CI using cel-go with the same CEL expressions as the VAP. It may be slower, but it gives you a concrete list or diff of the objects that would fail before the policy reaches the cluster.
For a staged in-cluster rollout, start with narrow matchConditions—such as specific namespaces or labels—and expand the scope only after a background scan reports no new violations. Kyverno background scans or a small controller that feeds live resource specs into cel-go can work for this. Once the policy is active, audit mode helps with newly created or updated objects, but a separate point-in-time scan is still needed for idle workloads.
That sounds very close to what I need. Being able to evaluate the policies before installing them is the key part.