Kyverno - Simplify Managing K8s Clusters
Tags: kubernetes, devops, cloud, tutorial
Published: 2021-03-02 13:52:41

Kubernetes was made with the aim to reduce the complexity while deploying production-ready applications. But just like every other piece of brilliant technology as the use-cases grew, managing Kubernetes clusters itself started becoming a complex task. One of these complexities which arose was managing configurations in a cluster. To simplify managing your K8s cluster, I want to introduce you to [Kyverno](https://kyverno.io/).

So let's get started!

## What Is Kyverno?

Kyverno, Greek for “govern”, is a policy engine designed for Kubernetes.

But what is a "policy engine"?

Kubernetes has four main categories when it comes to [policies](https://kubernetes.io/docs/concepts/policy/): Limit Ranges, Resource Quotas, Pod Security Policies, and Process ID Limits And Reservations.

To understand what a policy engine does let us first look at what Pod Security Policies are. Pod Security Policies are described as follows in the official [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/):

"A Pod Security Policy is a cluster-level resource that controls security sensitive aspects of the pod specification. Pod Security Policies enable fine-grained authorization of pod creation and updates."

Policy engines take this one step further by not only giving you a far greater amount of options but also allowing you to extend this fine-grained control beyond pods to other Kubernetes resources as well.

To put this in very simple terms, Kyverno allows you to define policies that can validate, mutate, and generate Kubernetes resources.

And you know what's even cooler?

Kyverno allows you to do this using the same familiar declarative approach of writing YAML files, using similar syntax as for your Kubernetes resource definitions. This means the learning curve is practically non-existent for K8s users!

## Why Kyverno?

Now that you have an idea of "what" Kyverno is I think you can start to understand why it is a really effective tool to have in your arsenal when fighting against the challenges of managing a Kubernetes cluster. Kyverno was created to simplify the process of validating and/or enforcing best practices for configurations in K8s clusters.

For those of you familiar with other policy engines like Open Policy Agent (OPA) might wonder why you'd want to use Kyverno? The reason is simple, it's the Kubernetes-native approach!

"Wait, what?"

Let me explain that in more detail. Anyone working with Kubernetes is familiar (and probably in love) with the simple declarative approach K8s takes of writing YAML files. Kyverno too believes in this ideology of keeping things simple and uses this same approach of writing YAML files to define your policies. This is in contrast to other engines like OPA for which one would have to learn Rego which has quite a learning curve.

So to sum it up, Kyverno is easy to learn and use yet extremely powerful!

## How Kyverno Works

Let me go a bit to the technical side of things and show you how Kyverno works on the inside. Kyverno relies on [Kubernetes Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). If you're not familiar with admission controllers, you can think of them as a sort of a checkpoint for Kubernetes API requests. At these checkpoints, the API requests can be mutated and/or validated/blocked.

Kubernetes comes with several built-in admission controllers but the two that are relevant to Kyverno are: [`ValidatingAdmissionWebhooks`](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) and [`MutatingAdmissionWebhooks`](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook). These two admission controllers receive an action from the REST endpoint of a service running inside the cluster, which is Kyverno. Based on this action received these admission controllers mutate or validate the API request as needed.

To make the whole picture extremely clear think of it this way: the two admission controllers talked about above receive an API request, they then send this request to Kyverno which, based on the policies you have written, decides what to do and sends this decision as a response to these controllers which then actually perform the action that needs to be taken.
<br/>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4vn2gverdop1fxlgu0z0.png)
<br/>

Interesting right?

What's even more interesting is that these policies you write in Kyverno are a [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). For those not familiar, custom resources are a way to extend Kubernetes by introducing a new object type. You can have a look at the schemas of the Custom Resources that Kyverno creates using the `kubectl explain` command. For example, to view the Kyverno policy schema you can run:

```
kubectl explain policy.spec
```

From a top-level view, you can look at Kyverno as a tool for managing your Kubernetes configurations with the help of policies. These policies can not only set the rules and validate the requests that the API Server receives but can also mutate the incoming Kubernetes object as part of the request. And all of this happens in the familiar declarative Kubernetes way.

## When Should You Use Kyverno

Due to the simplicity of Kyverno, you can use it on clusters of any size to make your life easier. You will particularly see Kyverno shine on complex clusters where a lot of configuration is required. In your clusters, Kyverno policies can help you by providing the defaults for a configuration and/or making sure you mistakenly don't end up creating resources that aren't following best practices.

There is a set of policies that check for (and enforce **if** you want) these best practices in the [kyverno/policies](https://github.com/kyverno/policies) repository. Apart from these the repository also has a huge collection of useful policies already present for you to use directly!

## Who Made Kyverno Possible

Kyverno was developed by [Nirmata](https://nirmata.com/), who provides cloud-based Kubernetes management platforms. The goal was to accelerate the adoption of Kubernetes which is only possible when it is easy to manage complex configurations. In November 2020, Kyverno joined the [Cloud Native Computing Foundation](https://www.cncf.io/) (CNCF) as a Sandbox project. Being a part of the CNCF was a step towards seeing more involvement from the community and a greater adoption of Kyverno as the de facto way of managing Kubernetes configurations.

## Where Can You Get Involved

There are a lot of amazing things about Kyverno but I think I forgot to mention the best one.

It's [open-source](https://github.com/kyverno)!

If you have some ideas or suggestions, you can open up issues related to them on the [Kyverno repo](https://github.com/kyverno/kyverno). You can also join the [Kyverno slack channel](https://app.slack.com/client/T09NY5SBT/CLGR9BJU9) and chat with the maintainers and other Kyverno community members. You can also join us at any one of the monthly [Kyverno community meetings](https://docs.google.com/document/d/10Hu1qTip1KShi8Lf_v9C5UVQtp7vz_WL3WVxltTvdAc/edit#heading=h.ulc3pq1azmlq)!

Kyverno has been [rapidly growing](https://starchart.cc/kyverno/kyverno) and we would appreciate it a lot if you could [star the project](https://github.com/kyverno/kyverno/stargazers) on GitHub and share it with others who might find it useful :)

If you want to contribute code you can get started with some of the ["good first issues"](https://github.com/kyverno/kyverno/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) on the repository. Kyverno comes with [excellent documentation](https://kyverno.io/docs/) and support from not only the maintainers but also other community members, so don't hesitate to ask if you have any queries whatsoever!