Recently, Cloud Native Live featured a session diving into the powerful integration of Common Expression Language (CEL) in Kyverno 1.14. Hosted by Eric Durmishi and presented by Kyverno maintainers Mariam Fahmy and Charles Edward, the session introduced exciting new capabilities that enhance Kyverno’s flexibility and consistency as a policy engine for Kubernetes.

What is Kyverno?

At its core, Kyverno is a policy engine for Kubernetes. It enables you to define policies for validating, mutating, generating, or verifying images for resources within your cluster. When an API request, like creating a Pod, is sent to the Kubernetes API server, it passes through several stages, including authentication and authorization. Kyverno integrates as an admission webhook. The API request is forwarded to the Kyverno server, which fetches relevant policies, applies them to the resource, and then either accepts or rejects the request based on whether the resource violates the policy.

Kyverno also includes components such as the Reports Controller, which generates policy reports to visualize policy results, and a Cleanup Controller, which manages unused resources based on cleanup policies.

Traditionally, Kyverno used a single policy type with different rule types nested within it, such as validate, mutate, generate, and verifyImages. Policies could define rules to match or exclude specific resources. For validation, you could use patterns, deny rules, Pod Security subrules, or assertion trees. If a resource violated a policy, Kyverno’s action was determined by the failureAction field, which could be set to enforce (reject the request) or audit (allow the request, generating a warning and a policy report).

Evolving Challenges and the Rise of CEL

While the traditional single policy type offered flexibility, it led to challenges. Defining validation logic involved multiple approaches (pattern, deny, Pod Security, CEL subrule, assertions), making it challenging to determine the best method. Furthermore, configuration fields, such as validationFailureAction, were specific to certain rule types (validate) but did not apply or make sense for others (generate), leading to potential confusion. Managing the increasing number of features within a single policy type became difficult.

Recognizing the need for a more consistent and focused approach to writing policies, and observing the growing momentum of CEL within Kubernetes (utilized in CRD validations and native admission policies), the Kyverno team decided to introduce new policy types. These new types leverage CEL extensively, allowing Kyverno’s functionality to be applied not only to Kubernetes resources but also potentially to any JSON payload.

Introducing New Policy Types in Kyverno 1.14

Kyverno 1.14 introduces new policy types, initially focusing on validating and image validating policies, with plans to add mutating, generating, and cleanup policies in future releases.

Validating Policy

The Validating Policy is a new Custom Resource Definition (CRD) that provides a structured way to define validation rules using Cloud Event Language (CEL). Key components of a Validating Policy include:

• failurePolicy: Determines how the API server reacts if an error occurs during policy evaluation (e.g., fail or ignore).
• validateActions: Specifies the action Kyverno takes if validation rules are violated. Can be a combination of ‘deny’, ‘warn’, or ‘audit’. Deny rejects the request, while Warn and Audit allow the request but generate warnings and policy reports, respectively.
• evaluation: Specific to Kubernetes, it allows for configuring background scanning or admission-time validation.
• autogen: Can do two things: 1. Autogenerate rules for Pod controllers as described. 2. Generate Kubernetes ValidatingAdmissionPolicies if `autogen.validatingAdmissionPolicy.enabled` is set to true.
• matchConstraints and matchCondition: Define which resources the policy applies to. matchConstraints uses familiar selectors (such as namespace or object selectors), while matchCondition utilizes CEL expressions for programmatic matching based on resource properties.
• validations: Contains the core validation logic defined using CEL expressions. These expressions evaluate against the resource being admitted.

CEL Extensions in Kyverno Validating Policies:

Kyverno extends the standard CEL capabilities with custom libraries to enhance policy logic:

• resource library: Allows fetching, listing, and even posting resources from the underlying cluster.
• http library: Enables calling external or internal HTTP endpoints from within a policy.
• user library: Used to parse user information from the admission request, such as decoding Service Accounts.
• image library: Decodes container image references and provides access to image metadata.
• imageData library: Allows calling into OCI registries to retrieve payloads like manifests and media types.
• globalContext library: Accesses a cache maintained by Kyverno, configured via a GlobalContextEntry CRD, allowing policies to reference cached data from the cluster.

These extensions allow for more complex and dynamic policy logic, such as fetching configuration from a ConfigMap and using it to validate resource labels, as demonstrated in the livestream.

Policy Reporting and Tooling:

Kyverno leverages the Policy Report CRD, a standard from the policy working group, to report the results of policy evaluations. If a validation fails with warn or audit actions, the violation is tracked in a policy report.

Kyverno offers a CLI tool and a Playground for testing policies outside of a cluster. The CLI enables you to validate resources against policies locally, which is particularly useful for CI pipelines. The playground provides a web-based interface for experimenting with policies and resources.

Image Validating Policy

The ImageValidatingPolicy is another new CRD specifically designed for validating container images. It shares features with Validating Policies, such as autogen, failurePolicy, and validationActions.

Key aspects of the Image Validating Policy include:

• matchImageReferences: Specifies which images the policy applies to.
• attestor and attestation: Used to verify image signatures and attestations.
• validations: Contains CEL logic to verify image signatures or attestations.
• Supports verifying signatures from Notary and Cosign.

This policy type is crucial for enforcing software supply chain security by ensuring images are signed and verified before they are allowed to run.

Future Directions

Introducing these new CEL-based policy types in Kyverno 1.14 is a significant step. Future work includes:

• Implementing mutating, generating, and cleanup policies using the new CEL-based structure.
• Developing a migration tool to help users transition from the older policy format to the new one.
• Potentially deprecating the older policy types in favor of the new, more consistent ones, although this is not planned for the immediate future.
• Actively contributing to upstream Kubernetes to make Kyverno’s CEL extensions, like the image library, available natively in Kubernetes validating admission policies. This leverages the API server’s programmability, reducing policy execution latency by avoiding external calls.

Kyverno’s Strengths

The livestream highlighted several key selling points for Kyverno:

• Flexibility: Adapting to various policy enforcement needs.
• Tooling and Reporting: Comprehensive ecosystem with policy reporting, dashboards (Policy Reporter), and CLI tools.
• Vast Ecosystem: Integration with other tools like Kyverno JSON (though features are now merged into core Kyverno) and an Envoy plugin for service mesh policies.
• Modern Approach: Leveraging standard technologies like YAML and CEL, and contributing to native Kubernetes capabilities.

In summary, Kyverno 1.14’s integration of CEL marks a significant evolution. It provides a more structured, consistent, and powerful way to write and enforce policies in Kubernetes and potentially beyond, building on its strengths while addressing previous challenges.