Admission and background checks

When does the rule run?

An admission check examines a request before Kubernetes accepts a change. A background check examines objects already stored in the cluster. Imagine checking a new visitor at the door versus inspecting the rooms later: the second can find a problem that already exists, but finding it does not itself undo it.

What decision does the policy make?

For the first MicroBank policy, require an explicit owner on the Pod template of Accounts and Ledger Deployments. This small rule gives you clear passing and failing cases to inspect. It does not certify authentication, financial correctness, or full workload security.

Admission evaluates a matching API request. Background evaluation examines existing matching objects and produces findings. Reporting an existing violation is not the same as repairing or deleting it. Test both paths if you intend to rely on both.

Use the API for the installed release

The current Kyverno documentation presents CEL-based ValidatingPolicy under policies.kyverno.io/v1 and marks ClusterPolicy as deprecated. The accompanying lab uses the documented CEL type. Older installations may require another API version; inspect their installed CRD and version-specific documentation rather than changing only the apiVersion line.

For this rule, match Deployment CREATE/UPDATE operations and constrain evaluation to the microbank namespace and the two named application Deployments. This keeps policy administration separate from unrelated controllers and database Pods. For production, review bypasses through other resource kinds separately; this lab intentionally covers only the two Deployments.

Read the owner rule as four questions

The policy lab contains the full version-specific YAML. First understand its logic without installing an engine:

1. Which request? Deployment creation or update.
2. Which objects? Accounts or Ledger, in the microbank namespace.
3. Which field? spec.template.metadata.labels, the labels used for Pods created by the Deployment.
4. Which value? platform.learnwithsk.dev/owner must equal microbank.

Why not check only metadata.labels? That labels the Deployment object. The Pod template is nested under spec.template; a value on the parent alone is not the same field. This distinction is easy to miss when reading a large manifest.

Predict the results before looking at the lab: correct Pod-template value passes; missing value fails; wrong value fails; value only on the parent fails. A Service or unrelated Deployment is outside this example's scope and should not be counted as a passing ownership check.

The CEL expression uses presence tests before reading the nested label. CEL is an expression language used here to return a validation decision; the rule is not a shell script and cannot repair the label. The lab's message explains the required change to the author.

Try it

Explain where an ownership label belongs: Deployment metadata, Pod-template metadata, or both. The policy checks the template because that is the label future Pods inherit. A label on the parent alone will fail this specific rule.

List resources the rule should ignore and why. Include a Deployment in another namespace and a Service. Matching zero resources is not a successful negative test.

Checkpoint and revision

Distinguish policy mismatch, evaluation error, webhook unavailability, and application failure. They need different fixes. Keep the rule's message tied to the field a developer can actually correct.

Compare your reasoning

A background report finding a violation does not delete the object. An admission rejection prevents the matching request from being accepted, subject to installed policy behavior. The following bite teaches how Audit and Deny change that decision.

Sources

Kyverno ValidatingPolicy↗, Kyverno releases↗, Policy reports↗.