How are you testing Validating Admission Policies on existing clusters?

November 15, 2026 4 answers
Asked by Veldro.8n

I want to introduce Validating Admission Policies on an existing cluster, but Warn mode only catches requests as they happen. How can I find existing workloads that would violate a policy before enforcing it, preferably without installing another tool in the cluster or digging through audit logs?

Answers

m.718~bytegate

Take a look at kubeapt. It can evaluate policies against cluster resources before the policies are installed, including custom policies and built-in policy bundles. That looks like a useful way to get an initial picture of violations without deploying another policy engine to the cluster.

Check the tool's access requirements and how closely its evaluation matches the admission requests you care about before treating the results as a complete rollout check.

Veldro.8n:

Thanks, the ability to check custom policies before installing them is exactly the kind of workflow I was looking for.

Reply to this answer
Tavlo-8k

Kyverno is another option if you're comfortable running an additional tool in the cluster. Its background scanning can help surface violations in existing resources, rather than waiting for those resources to be updated and go through admission again.

The tradeoff is more operational overhead if you aren't already using it. That may be worthwhile for ongoing reporting, but less appealing if you just need a one-time assessment.

Reply to this answer
5r!dataclip_638

A more manual route is to export the relevant resource specs with kubectl and feed them into a local policy engine. You get an off-cluster assessment, but collecting the right resource types and processing a large number of objects can be tedious.

Make sure the local evaluation covers the policy behavior you need. A scan of stored objects and an actual admission request aren't necessarily identical.

Reply to this answer
7q+portmask_318

I'd still use Warn during rollout, just not as the inventory tool. An existing workload can sit there without generating a warning until a matching admission request occurs, so a quiet warning period doesn't prove the cluster is clean.

Use a scan or local evaluation to find existing violations, then Warn to catch requests as they happen before switching to enforcement.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions