Do You Still Need Kyverno with the new Kubernetes Policy Types?

With the addition of ValidatingAdmissionPolicy and MutatingAdmissionPolicy in Kubernetes, do you still need Kyverno?

TL;DR: Yes, you still need Kyverno for applying policies on existing resources, complex logic, reporting, testing, and off-cluster / shift-left use cases! Read on for details:

Introduction

Prior to Kyverno, policy management in Kubernetes was complex and cumbersome. While the need for Policy as Code was clear, initial implementations required learning complex languages and did not implement the full policy as code lifecycle.

Kyverno was created by Nirmata, and donated to the CNCF in November 2020. It rapidly gained popularity due to its embrace of Kubernetes resources for policy declarations, its easy to use syntax, and breadth of features that addressed all aspects of policy as code.

Recently, Kubernetes has also introduced native policy types that can be executed directly in the Kubernetes API server. This move validates that policies are a must have for Kubernetes, and now allows critical policies to be executed directly in the API server. 

The Kubernetes API server is a critical resource that needs to be extremely efficient. To safely execute policies in the API server, the Kubernetes authors chose CEL (Common Expressions Language) to embed logic in policy YAML declarations. In addition to a familiar syntax, CEL programs can be pre-compiled and execution costs can be pre-calculated.

With these changes in Kubernetes, Kyverno has also evolved to stay true to its mission of providing the best policy engine and tools for Kubernetes native policy as code. 

Kyverno now supports five new policy types, two of which, ValidatingPolicy and MutatingPolicy, are extensions of Kubernetes policy types ValidatingAdmissionPolicy and MutatingAdmissionPolicy, respectively.

NOTE: I will use the term “Kubernetes Policies” to refer to ValidatingAdmissionPolicies and MutatingAdmissionPolicies.

1. ValidatingPolicy: This policy type checks if a resource’s configuration adheres to predefined rules and can either enforce or audit compliance. This policy type is an extension of the Kubernetes ValidatingAdmissionPolicy.
2. ImageValidatingPolicy: A specialized validating policy that verifies a container image’s signatures and attestations to ensure its integrity and trustworthiness.
3. MutatingPolicy: This policy type modifies a resource’s configuration as it’s being created or updated, applying changes like adding labels, annotations, or sidecar containers. This policy is an extension of the Kubernetes MutatingAdmissionPolicy.
4. GeneratingPolicy: This policy creates or clones new resources in response to a trigger event, such as automatically generating a NetworkPolicy when a new Namespace is created.
5. DeletingPolicy: This policy automatically deletes existing resources that match specific criteria on a predefined schedule, often used for garbage collection or enforcing retention policies

So, when should you choose to use Kyverno policies vs the Kubernetes policy types? The right answer is that if you believe that declarative Policy as Code is the right way to manage Kubernetes configuration complexity, you will need both! 

As you will see below, Kyverno provides critical features that are missing in Kubernetes policies and also helps with policy management at scale.

1. Applying Policies On Existing Resources

When new policies are created, they need to be applied on existing resources. Kubernetes Policies only apply to resource changes, and hence, policy violations on existing resources are not reported.

Kyverno applies policies, including Kubernetes Policy types, on all resources including resources created before the policy. 

2. Reapplying Policies On Changes

Like code, policies change over time. This can be to adapt to updated or new features, or to fix issues in the policy. When a policy changes, it must be reapplied to all resources. Kubernetes Policies are embedded in the API server and not reapplied when the policy changes.

3. Applying Policies Off Cluster (Shift-Left)

Providing feedback to developers as early as possible in a deployment pipeline is highly desirable and has tangible benefits of time and cost savings. The Kyverno CLI can apply Kyverno and Kubernetes Policy types in CI/CD and IaC pipelines.

4. Testing Policy as Code

Like all software, policies must be thoroughly tested prior to deployment. Kyverno provides tools for testing Kyverno and Kubernetes policy types. You can use the Kyverno CLI for unit tests, and Kyverno Chainsaw for e2e behavioral tests.

5. Reporting Policy Results

Kyverno provides integrated reporting, where reports are namespaced Kubernetes resources and hence via the Kubernetes API and other tools to application owners. Kyverno reports are generated for both Kyverno and Kubernetes policy types.

6. Managing Fine-Grained Policy Exceptions

Kyverno allows configuring policy exceptions to exclude some resources from policies. Kyverno exceptions are Kubernetes resources, making it possible to view and manage via the Kubernetes API using standard tools. 

Kyverno exceptions can specify an image, so you can exclude certain containers in a pod while still applying the policy to other containers. Exceptions can also declare specific values that are allowed. Exceptions can also be time-bound, but adding a TTL (time to live). 

These powerful capabilities allow enforcing policies and then use exceptions to exclude certain resources, or even parts of a resource declaration.

7. Complex Policy Logic

Kubernetes policies are designed for simple checks and can only apply to the admission payload. This is often insufficient, as policies may need to look up other resources or even reference external data. These types of checks are not possible with Kubernetes policies. Additionally, Kubernetes MutatingAdmissionPolicies cannot match sub-resources and apply to a resource.

Kyverno supports features for complex policies, including API lookups and external data management. Kyverno also offers an extended CEL library with useful functions necessary for complex policies.

8. Image Verification

Kyverno offers built-in verification of OCI (Open Container Initiative) image and artifact signatures, using Sigstore’s Cosign or CNCF’s Notary projects. This allows implementing software supply chain security use cases and achieving high levels of SLSA (Supply-chain Levels for Software Artifacts.)

9. Policy-Based Automation

Besides validating and mutating resources, policies are an essential tool for automating several complex platform engineering tasks. For example, policies can be used to automatically generate secure defaults, or resources like network policies, on flexible triggers such as namespace creation or when a label is added. This allows a tight control loop and can be used to replace custom controllers with declarative and scalable policy as code.

10. Kyverno Everywhere

While Kubernetes Policy types can only be applied to Kubernetes resources, Kyverno policies can be applied to any JSON or YAML payload, including Terraform or OpenTofu manifests, other IaC manifests such as CDK,  and build artifacts such as Dockerfiles.

Kyverno enables a unified policy as code approach, which is essential for platform engineering teams that manage both Kubernetes clusters and pipelines for CI/CD and IaC.

Conclusion

Kyverno is fully compatible with Kubernetes policies and is designed to seamlessly support and extend Kubernetes policy types. It applies Kubernetes policies to existing resources and can also provide policy reporting and exception management for Kubernetes policies.

Like Kubernetes policies, Kyverno policies also use the Common Expressions Language (CEL) and extend the Kubernetes policy declarations with additional fields and extended CEL libraries required for complex policies and advanced policy as code use cases.

This allows for a mix of Kubernetes and Kyverno policies to be managed by Kyverno. You can get started with Kubernetes policies and then upgrade to Kyverno policies for advanced use cases.

If you have existing Kubernetes policies, you can use Kyverno to apply them to existing resources, produce reports, apply the policies off-cluster, and perform unit and behavioral tests.

If you are starting out, you can use Kyverno policy types. Wherever possible, Kyverno will automatically generate and manage Kubernetes policies for optimal performance. For complex policies that cannot be handled in the API server, Kyverno will execute these during admission controls and periodically as background scans. 

Regardless of where you start, with Kyverno, you get a powerful and complete policy as code solution for Kubernetes!

 

FAQ: Kyverno vs Kubernetes Policies

What is the difference between Kyverno and Kubernetes policies?

Kubernetes policies validate or mutate resources at admission, but lack reporting, automation, and supply chain features. Kyverno extends them with reporting, testing, and broader policy types.

Can Kyverno replace Kubernetes ValidatingAdmissionPolicy?

Yes, but its best to use both! Kubernetes policies handle simple admission request logic, while Kyverno adds complex logic, background processing, scale, reporting, and complete policy-based resource lifecycle management. In fact, Kyverno will automatically generate Kubernetes policies whenever possible.

Why do I need Kyverno if Kubernetes already has policies?

Kubernetes policies are limited to simple admission request logic (see above). Kyverno can apply policies off-cluster, supports CI/CD, automates resource creation, and handles non-Kubernetes manifests.