Overview

Kubernetes (K8s), or its enterprise distribution OpenShift, has become a de facto solution for container platforms. Enterprises that run Kubernetes/OpenShift at scale and in multiple clusters face challenges to maintain the sanctity of the clusters, and when multiple teams of different backgrounds work on the same platform, it becomes increasingly more challenging to ensure everyone does the right thing. In fact, it's a requirement to have a mechanism in place that allows organizations to define and enforce policies so that developers and admins maintain a certain standard —and the mechanism should not bring extra overhead for operations and maintenance.

Kyverno is one such solution that allows cluster admins to manage environment-specific configurations, enforce security best practices and help clean up. In this article, we will explore Kyverno and map it to our requirements and use cases where it can be useful.

What is Kyverno?

In the Greek language, Kyverno means 'to govern.' In the technology world, it is a policy engine software solution that works as a dynamic admission controller. Kyverno is open-source and community-supported, and its policies are written in YAML as Kubernetes resources, which makes them simple and readable. YAML stands for "yet another markup language." It is a human-readable data serialization format often used for configuration files and data exchange between languages with different data structures.

These YAML-written policies aren't only for pods —they can apply to almost all Kubernetes objects. The scope can be defined for the namespace level or the whole cluster. Below are the main features and capabilities of Kyverno.

Enforce security and best practices using Kubernetes-native policy management with Kyverno.

Share  

1. Validation, mutation, generation and cleanup of resources
2. Sync configuration across namespaces
3. Block or report non-conformant resources using admission controls.
4. Policy as K8s resource and policy audit feature
5. OpenAPI validation schema
6. Self-service reports and exception

As Kyverno works as a dynamic admission controller, we can enforce the security policies and best practices for every K8s push request; using Kyverno CLI, we can check the policy behavior to resource even before adding them in a cluster, e.g., in the CI-CD pipeline. We can check whether the request is at par with the cluster security and best practices of the cluster where we will deploy the workload.

Kyverno Policy and types

In OpenShift or Kubernetes, there are two webhooks: mutating and validating. Kyverno is designed to work as an admission controller and has one additional capability: generation. Kyverno policy is a collection of rules, where each practice consists of a match declaration through which we control what type of object this applies and an optional exclude declaration that selects all but excludes resources that match the specified criteria. Each rule can contain only a single validate, mutate, generate or verify images child declaration, which decides what to do on the object selected in the match declaration.

Policies can be applicable for only a namespace using the K8s object 'Policy' and for all namespaces in the cluster using the 'ClusterPolicy' object.

We can write three types of policies:

1. Validation Policy: Rules to check mandatory properties of the resource. If properties and rules match, it passes on the API request.
2. Mutation Policy: Patch incoming requests to modify resources and make them applicable for the cluster and consistently execute before validation policies. For example, you may want a specific label attached before creating a deployment in Kubernetes. Even if you forget to add it before applying the configuration, the mutating webhook will add it before creating the resource.
3. Generation Policy: Creation of additional (new) objects and resources, e.g., network policy creation on every new namespace creation.

Installation

Kyverno is a policy engine installed and worked upon as a webhook of the admission controller. As it is a central piece affecting all requests to the cluster, we need cluster admin access to install it. We can install Kyverno by adding helm repo or by deploying YAML.

To pass through validation against any OpenShift security context constraints, we must pass --set securityContext=null.

Kyverno does not support two replicas. For a highly available installation, the only supported count is 3. It is required to provide cluster-admin access to the Kyverno service account so that it can check and control all API requests. The library has many policies of different categories, accessible as a web page — https://kyverno.io/policies/ — to explore and apply based on requirements.

Things to consider while deploying Kyverno

Like any technology, the control over its usage is the key to its success. Working closely with clients and exploring its vast features, we've identified some pointers to remember while going ahead with Kyverno.

1. Analyze what we need: Many policies are already drafted in the library and the community is adding more, but not all that is available is applicable. Any policy that is not required for the setup is irrelevant, and keeping those that are irrelevant may create an issue down the road. Not all best practices are applicable for all environments, e.g., in prod, we have more blockages and restrictions that are not applicable in the dev environment.
2. Design for collaboration: Policies should consider everyone, not just those with admin privileges. This allows policy results to be shared, seen and discussed among all groups. Such forethought leads to improvements over time. Using policy-reporter-UI is a well-suited solution for this.
3. Understand the risks: Kyverno will be installed and maintained in a highly available fashion because it works as an admission controller, and if it is not healthy or unavailable, no new request will be processed and affect the whole cluster. GitOps engine, e.g., flux CD, argoCD, etc., is used to provide awareness of resource parameters mutated/generated by Kyverno or explicit exceptions to be designed.

Kyverno and its benefits for the uninitiated

Kyverno is built for Kubernetes and applies to pods and almost all K8s resources. Its main features include validation, mutation, generation and cleanup of resources, syncing configuration across namespaces, blocking or reporting non-conformant resources using admission controls, the policy as K8s resource, policy audit feature, OpenAPI validation schema and self-service reports and exceptions. Its benefits include:

1. Kyverno uses plain YAML, saving training costs of learning (new tools/ language) and maintaining skilled resources
2. Kyverno is built for Kubernetes and applies to pods and almost all K8s resources
3. It has a feature to test policy behavior against resources before hitting an actual cluster
4. It also offers community support and an extensive policy library, preventing the need to write policies from scratch
5. Policy reports clarify policies and resources and can be accessed and downloaded from a policy reporter-UI tool