Introduction to Kyverno

The Kubernetes API can evaluate certain API requests itself with the CEL expression language, while Kyverno provides additional policy workflows. Using a shared Kubernetes validation requirement, you compare native ValidatingAdmissionPolicy with Kyverno in operation and consider when the native option is sufficient. Example workloads illustrate evaluation location and feedback.

CEL describes conditions that Kubernetes and Kyverno evaluate without imperative control flow. You extend a simple rule with safe field access, variables, all, and exists while considering CREATE and UPDATE. In the lab environment, you vary missing and unexpected fields and examine how the expression responds.

A policy is useful only when it targets exactly the intended resources. You complete a ValidatingPolicy with scope, a CEL expression, and clear feedback. In the DevNinjas Dojo, our cloud learning environment, you compare offline evaluation with admission behaviour in the cluster for the same policy cases to consider differences between both execution paths.

Before blocking enforcement, the affected resource estate must be understandable. You compare new API requests with background checks of stored resources and interpret the different result types. In the lab environment, you examine which findings still need to be clarified before rollout and before you consider a blocking rule.

An exception needs a reason, an owner, and tightly constrained scope. In the training environment, you define a PolicyException through policy references and match conditions and examine matching and non-matching requests. In the lab, you compare Audit and Deny; you discuss rollback for a controlled introduction.

Mutations can add defined platform standards but must respect existing configuration. In a MutatingPolicy, you compare declarative and targeted changes for a workload default. In the lab environment, you examine repeatability, existing values, and conflicts and assess idempotency; you then discuss how the same test idea can be reused after later changes.

When Kyverno, a GitOps controller, and a user all change the same field, a continuous conflict can result. You apply mutateExisting to selected resources and use a GitOps diff, events, and managedFields to observe how competing updates become visible. In the lab, you discuss field ownership, RBAC permissions, and the boundary between diagnostic information and technical overwrite protection.

New namespaces may require consistent baseline resources for a platform. For suitable namespaces, use a GeneratingPolicy to create resources from data definitions and keep them in sync. In the lab, you compare visible updates, conflicts, and resources left behind and discuss sensible responsibilities and shared boundaries between the policy and platform teams.

Automated deletion requires a clearly defined target set and appropriate permissions. You restrict a DeletingPolicy with labels and CEL conditions and examine selection and access boundaries. Suitable observations support assessment of the intended scope, including which resources should remain untouched, before possible use in the cluster.

Some rules need data beyond the current API request. Using permissions, destinations, authentication, timeouts, and freshness, you compare runtime access through resource.Get and http.Get with the cache used by globalContext.Get, including risks from latency, failures, and staleness. GlobalContextEntry at kyverno.io/v2 is a stable supporting resource.

A digest identifies image content by its hash; 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 identities, issuers, subjects, and registry boundaries. The focus is the contribution that identity verification, attestation content, and the CEL decision each make.

A valid signature alone is not enough; image verification connects trust data with selected images. You complete an ImageValidatingPolicy and vary signature status, identity context, and attestation content without predetermining an acceptable outcome. From the resulting feedback, you distinguish policy violations from technical failures; validationActions handles rule violations, timeoutSeconds limits the wait, and failurePolicy controls fail-open or fail-closed behaviour.

Policy changes should be checked before cluster rollout. You pin the Kyverno CLI version and add schema and behaviour tests to a CI job. In the lab environment, you record in a comparison of both approaches which checks work offline and which still require a cluster.

The availability of an admission webhook affects availability or enforcement depending on its configuration. You investigate a failure through selected Kubernetes metrics, events, and Kyverno logs in the cluster and include failurePolicy and timeoutSeconds in your hypotheses. After a failure, suitable checks can be used to assess functionality.

Existing Policy and ClusterPolicy estates need a planned transition to the CEL-based APIs. You relate a validation rule to the appropriate policy type and run the same test cases before and after migration. In peer review, you examine ownership, observation periods, promotion criteria, reversal options, and the limits of transferring the exercise to production.