Simplify Kubernetes Cluster Management with Kyverno

The introduction of Kubernetes( K8s) aimed to eliminate the difficulties and complexities encountered when deploying and scaling containerized applications. It has since grown in popularity and appears to be the most talked-about container orchestration tool. Yet, like every other fast-growing technology, K8s had its downsides, such as configuration complexity, lack of automation, and security challenges with insecure defaults.

To tackle this problem and maintain the standards of K8s, "Kubernetes policy management engines" were introduced by the community. These policy engines would then permit the automation and secure handling of Kubernetes configurations by regulating configurations and which applications could run within a particular K8s cluster. This need resulted in the development of two CNCF projects and leading policy engines that can be leveraged to manage policies in a Kubernetes environment, OPA and Kyverno. This article will give you a quick intro to Kyverno, a simple analogy to how it works and why it is considered the ideal policy engine.

What is a policy engine?

In a Kubernetes(K8s) environment, there are a lot of dynamically moving parts, and to keep tabs on them, K8s uses the concept of "policy." K8 Policies are used to define settings that should apply across the cluster. Policy engines deliver several options in gaining control of Kubernetes resources.

K8s policies are seen in four categories: Limit Ranges, Resource Quotas, Pod Security Policies, and Process ID Limits and Reservations.

What is kyverno?

Kyverno is an Open source policy engine explicitly designed for Kubernetes. The word "Kyverno" is a Greek word for "Govern". It was initially developed by Nirmata and is now a CNCF sandbox project.

Kyverno allows you to define policies, as Kubernetes resources, that can Validate, Mutate, and Generate other Kubernetes resources. Unlike OPA, which requires you to understand Rego language to define policies, Kyverno is specifically designed to use Kubernetes-style composition and leverage the Kubernetes API metadata to learn the structure of Kubernetes resources. Kyverno uses the YAML files approach and a similar syntax as your K8s resource definitions.

Why Kyverno?

Well, you must be wondering by now what makes Kyverno stand out from other policy engines and why it's considered the ideal policy engine.

Let's get to it!.

Simplicity Kyverno follows the K8s simple declarative approach by writing in YAML files. YAML is a language that is common amongst developers, and it is quite easy to understand. In contrast, OPA has its programming language called Rego and it is required to work with policies and making decisions. Kyverno is used to manage clusters of any size with ease. This provides its users with high flexibility when developing policies.
Kubernetes centred Kyverno is a policy engine that was specifically created for Kubernetes to handle the difficulties of managing clusters. Kyverno works well with other existing Kubernetes developer tools, like kubectl, Kustomize, and Git.
Generate policies Policy engines are created with key capabilities that enable them to validate and mutate policies as needed. Whereas, aside from Kyverno's Kubernetes-native design, it possesses the ability togenerate policies. You can now leverage the same engine to Validate, mutate and Generate any resource.

All these put together are what make Kyverno simple yet powerful compared to other policy engines.

How does Kyverno work?

Kyverno runs as a dynamic admission controller in a Kubernetes cluster. There are two relevant built-in admission controllers in K8s, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks. The two admission controllers receive an action from the REST endpoint of a service running inside the cluster that is Kyverno. Based on this received action, these admission controllers return results that enforce admission policies or reject requests.

Kyverno policies can match resources using the resource kind, name, and label selectors. Wildcards are supported in names.

To better understand how Kyverno works, let's break it down with a non-technical instance.

Imagine a firm with two receptionists (admission controllers - ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks). When packages(Kubernetes API requests) are delivered for the CEO, these receptionists will each carry these packages to the manager(Kyverno). The manager now will review the packages delivered and cross-check to make sure the packages delivered meet the specifications(policies you have written) directed by the CEO. These packages are examined based on the name on the package, the sender, the labels, and the kind of package it is.

After scrutinizing these packages, the manager will send the final decision concerning the packages as feedback to these receptionists (ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks). The receptionists can then go ahead and carry out the necessary actions that need to be taken, like stamping the packages or make some notes on the packets received.

Conclusion

If you are still reading this, that means this project interests you too. Good news! It is an Open-source Project, so you are welcome to explore the GitHub repository and make your contributions as well; also, don't forget to Star the project. You can also join the Kyverno slack channel to connect with the maintainers and other Kyverno community members. You can also join us at any one of the monthly Kyverno community meetings!