Audit before enforcement

Separate a finding from a refusal

In this lesson, Audit means learning which matching requests violate the rule while allowing them through the rule's audit behavior. Deny means rejecting a matching request that fails validation. The result of evaluation and the decision to block are related but distinct.

Discover impact before blocking changes

Start the owner rule with validationActions: [Audit]. Submit matching compliant and noncompliant test fixtures and inspect the evaluation. In the live local exercise, a noncompliant request may be admitted while a report records failure. An allowed request is therefore not evidence that the rule passed.

Before switching to Deny, correct known violations, test the message, and identify who can repair the policy if it blocks an essential update. Review this change as you would an application release.

Define the rollout boundary

Scope the first enforcement exercise to the two MicroBank API Deployments in the disposable local namespace. Do not test a new cluster-wide restriction against system namespaces. Inspect policy readiness and admission events after installation; a YAML file stored in Git is not an active admission control.

Failure action and webhook failure behavior are distinct. A rule can deny a noncompliant object while a separate webhook setting controls what happens on evaluation timeout or infrastructure failure. Explain both before relying on enforcement.

Work through the expected outcomes

Other API validation, RBAC or policies can still reject any of these requests. That is why you must read the actual error rather than equate any rejection with a successful owner test.

An operational rollout follows the same sequence: exercise fixtures offline, review findings on the intended scope, fix legitimate workloads, then change enforcement. Write down the person and procedure that can restore Audit if a defective rule blocks valid work. That rollback is a policy change to review, not permission to disable every admission control.

For a paper exercise, assume the valid fixture begins failing after you change a match expression. Would you proceed because the invalid fixture also fails? No. You lost the positive control. Repair the rule and repeat both cases before evaluating its live behavior.

Try it

Prepare a change record with four entries: expected valid case, expected invalid case, scope exclusions, and rollback to Audit. Run the offline policy fixture first. Then use a server-side dry run against the explicitly selected local cluster to prove admission behavior without replacing the running Deployment.

Inspect the error: it must identify your owner rule. A rejection due to missing RBAC, an invalid Deployment selector, or an unrelated policy does not prove this rule works. After changing modes, repeat the valid case so a policy typo does not become an unexplained outage.

Checkpoint and revision

Show a reported violation in Audit and a rejected request in Deny, or record which step remains unexecuted. Verify both sides of enforcement: the invalid request is rejected and legitimate operations still work.

Compare your reasoning

A rule's Deny action addresses a known failed validation. Webhook timeout/failure settings address inability to evaluate the request. Do not claim to know outage behavior from the Audit/Deny setting alone. The local lab tests the declared rule; production availability needs separate design.

Sources

Kyverno applying policies↗, Kubernetes server-side dry run↗, Kyverno troubleshooting↗.