Introduction to Kyverno

Kubernetes can evaluate certain API requests itself with the CEL expression language. Using an "approved registries only" requirement, you compare a native ValidatingAdmissionPolicy with Kyverno. Two example workloads show where the rule runs and what feedback users receive. A decision table also covers the hybrid option in which Kyverno generates a native policy.

CEL is the expression language Kubernetes and Kyverno use to evaluate conditions. You extend a simple rule with safe field access, variables, all, and exists. Test objects with missing or unexpected fields show how the expression behaves on CREATE and UPDATE. A result matrix makes true, false, and evaluation errors easy to distinguish.

A policy is useful only when it targets exactly the intended resources. You complete a ValidatingPolicy with resource matching, a CEL rule, and a clear error message. You then run compliant, rejected, skipped, and UPDATE cases with kyverno test. For the same test cases, you compare the offline result with admission behavior in the cluster. The test overview remains in the repository as evidence.

Before blocking anything, you need to know which resources a policy would affect and why. You compare new API requests with background checks of existing resources and interpret pass, fail, skip, warn, and error. You document which findings are explained and which need correction before rollout. Policy Reports do not replace a complete history of rejected requests.

An exception needs a reason, an owner, and tightly limited scope. In the training environment, PolicyException is enabled and restricted to one administration namespace. Policy references and match conditions define which requests are actually exempt, and you test matching and non-matching cases. Only then do you move from Audit (observe) to Deny (block) and verify the documented rollback.

Platform standards are often easier to apply as automatic defaults than to check manually on every deployment. In a MutatingPolicy, you implement a workload default with declarative ApplyConfiguration and compare it with a targeted JSONPatch. Repeated execution, existing values, and conflicting input show whether the mutation remains idempotent and respects configuration owned elsewhere. The verified case remains in the repository as a regression test.

When Kyverno, a GitOps controller, and a user all change the same field, a continuous conflict can result. You enable the asynchronous mutateExisting function for selected resources and watch GitOps revert the change in the exercise. A GitOps diff and reconciliation events expose the conflict; managedFields supports diagnosis but does not prevent overwrites. You then define field responsibility and RBAC permissions.

New namespaces often need the same baseline resources. With a GeneratingPolicy, you generate a NetworkPolicy from a data definition for clearly labeled namespaces and then include an existing namespace. Changes to the trigger and synchronization show when Kyverno updates, collides, or leaves resources behind. You document which system manages the resource and what happens after removed triggers; a prepared trace compares clone mode.

Automated deletion requires a known target set. In a disposable namespace, you restrict a DeletingPolicy with opt-in labels and CEL conditions. A separate preflight query lists the same candidates; it is a safety check, not a Kyverno preview. Beyond its base permissions, the cleanup role needs get, list, watch, and delete on target resources. Events and a final inventory verify deletion and preservation.

Some rules need information beyond the current API request. resource.Get and http.Get read data at runtime and can add latency or failure dependencies. globalContext.Get uses a cache whose content may become stale. A decision matrix compares permissions, allowed destinations, authentication, timeouts, and data freshness. You also see when HTTP access must be enabled for namespaced policies. GlobalContextEntry remains experimental, with no stability promise.

A digest identifies an immutable image. Successful signature verification proves the cryptographic binding to a configured key or identity; an attestation provides additional statements about the build. In a supply-chain example, you classify keys, OIDC-based keyless identities, issuers, subjects, and registry boundaries. A risk-to-control mapping records what identity verification, attestation content, and the subsequent CEL decision each establish.

A valid signature alone is not enough. With prepared images and trust data in a local registry, you complete an ImageValidatingPolicy with guidance. A result matrix separates four cases: correctly signed, unsigned, wrong identity, and a validly signed attestation with disallowed content. You distinguish policy violations from technical failures: validationActions handles violated rules, timeoutSeconds limits the wait, and failurePolicy then determines fail-open or fail-closed behavior.

Policy changes should not first reveal their problems in a cluster. You pin the Kyverno CLI version in the shared repository and add schema and behavior tests to a CI job. A faulty policy commit stops the pipeline; after the correction, it passes. You record which checks work offline and which still require a cluster.

If the admission webhook becomes completely unavailable, Kubernetes may block legitimate deployments or skip controls. You first define failurePolicy and timeoutSeconds. A prepared fault then makes every webhook endpoint unreachable. You trace the cause through metrics, events, and logs. Recovery through an independent administrator path ends with functional checks for one compliant and one violating request.

Existing Policy and ClusterPolicy resources do not disappear when the API changes. You move one validation rule to the appropriate CEL-based policy type and run the same test cases before and after migration. When compliant, rejected, skipped, and excepted cases match, the peer review records ownership, observation period, promotion criteria, and the way back.