Let's get into it…
An organization that needs to follow compliance and look for a policy engine has two main options when it comes to Kubernetes. One of them is Kyverno (Greek for “govern”), a policy engine tool specifically for Kubernetes.
Kyverno admission controller
In Kubernetes, we know that we interact with the Kube API Server to deploy new resources to the cluster. But it’s less known that we have admission controllers that can validate and mutate the API request we tried to execute. A simple example of it is when you deploy a pod to a non-existent namespace and get an error namespace “something” not found. Thanks for the NameSpaceLifecycle admission controller we are being validated before creating a resource to none existing namespace.
Kyverno implements a dynamic admission controller. Once an API request is been sent to the API server Kyverno is able to review the request and pick action according to a policy that we had set beforehand.
Kyverno In Action
Let’s take Kyverno into action and let’s implement a real-life scenario where we want to check that the registry used by the main container will always be the company registry called company.org. In the post, we are using K3d, but feel free to use any other bootstrap tool so you can follow the blog. We will start by installing the Kyverno helm chart in standalone mode.
Once the helm chart has been installed successfully we can start and execute our policy. It's nice to know that Kyverno has created ready-to-use policies that can be installed as a helm chart and can help you set some best practice policies straight from the get-go (See link below). With that being said will be using the CRD policy to implement a policy on a single namespace
If we are looking at the status of the policy we can see that Kyverno has an auto-generate capability and adds to the policy also to higher-level controllers such as Deployment and Statefulset. Without the auto-generate capability we could be able to create the deployment but it would fail to schedule the pod can create a confusing situation for the cluster operator.
If we try to run a pod or create any other higher-level controller that doesn't follow up with the policy, it would fail with the error message provided in the policy.
To conclude,
Kyverno is a policy engine tool that is in an incubating state in CNCF, from our own experience with the tool it's a great choice if you want to implement policy on the Kubernetes cluster as it does not require a big learning curve to implement and help you to implement best practice policy from the get-go.
Relevant links:
Kyverno - https://kyverno.io/docs/writing-policies/autogen/
Kyverno-policy - https://github.com/kyverno/kyverno/tree/main/charts/kyverno-policies