Last updated Sept 8, 2022

Kyverno is an open source Kubernetes native policy engine that Nirmata created in 2019 and donated to the Cloud Native Computing Foundation (CNCF) in 2020. Since then, Kyverno has been downloaded more than 300 million times and graduated from Sandbox to Incubator status in less than 18 months. With the most stars of any policy engine on Github, it’s become the de facto standard in Kubernetes policy management.

My co-founder and I both came from the telecommunications industry where managing critical infrastructure at scale relied on implementing IT policies. As the container ecosystem continued to grow in complexity, they saw an opportunity.

We founded Nirmata to apply our policy-based approach to Kubernetes and empower DevSecOps team with native tools to manage and automate configuration and security.

In this post, I will discuss why policy management is important for enterprise Kubernetes, and share what Kyverno can do for you.

What is Policy Management

Kubernetes provides a declarative management interface. Users can specify the desired state of the system using API definitions, and Kubernetes controllers then work to make the current state match the desired state. This approach is used for managing cluster nodes and services as well as for managing application workloads.

A policy typically represents required configurations. Kubernetes itself provides several policies such as:

• Network Policies: to secure network traffic to and from pods
• Pod Security Policy: to control privilege and access profiles for pods 
• Quotas and Limit Range: to manage resource utilization and fairness

These policies are native API objects that govern the behavior of the Kubernetes cluster. However, there are several situations where users want to configure settings that are required cluster-wide and even across clusters within an enterprise. These Kubernetes constructs are powerful but have no effect if not configured. And configuring them correctly, for multiple workloads is a non-trivial task.

For successful adoption and growth of enterprise Kubernetes, an organizational pattern that is emerging is that an internal platform team is formed to manage Kubernetes clusters, infrastructure for Kubernetes, and all of the common services that must run in each cluster or are shared across clusters, and are required to operationalize Kubernetes (e.g. for monitoring, logging, security, backup and DR, etc.). 

The platform team provides Kubernetes services and solutions to product development teams within the enterprise. The platform team would also be responsible for setting the policies for the security and proper configuration and operations of Kubernetes clusters and workloads – for example, by mandating that resource quotas are required on all shared clusters. 

To scale Kubernetes usage, it is necessary that a central team is responsible for ensuring proper configuration of Kubernetes policies, and validation of other best practice guidelines, This is why Kubernetes policy management is becoming increasingly important for enterprise Kubernetes.

Why Kubernetes Native

In this section I will discuss what being Kubernetes native means, and why that important for a policy management solution.

Kubernetes is designed to be extended using Custom Resources. Custom Resources allow us to introduce a new object type, and use it via any tool that can interact with the Kubernetes API. For example, custom resources can be specified in YAML. This allows us to apply declarative management principles using tools such as Kustomize.

The Custom Resource mechanism allows us to extend Kubernetes and utilize common tooling for managing Kubernetes configurations. Policy management is a form of configuration management, where a policy provides defaults for configuration and also determines what is allowed or disallowed. Hence it is important that a Kubernetes policy management solution also adopt the same practices and approach as Kubernetes management.

What Kyverno Does

Kyverno allows cluster administrators to validate, mutate, and generate configurations. Kyverno policies are Kubernetes resources. The policies match other resource based on Kubernetes label selectors with support for wildcards. Kyverno uses Kubernetes events to report policy enforcement.

Kyverno also monitors changes on policies, and scans existing resources for policy violations. Policy violations are reported as sub-resources on the policy object. 

Here is an example of a Kyverno policy that validates that images are only pulled from an allowed list of image registries (based on wildcard patterns):

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: check-registries
spec:
  rules:
  - name: check-registries
    resource:
      kinds:
      - Deployment
      - StatefulSet
      validate:
       message: "Registry is not allowed"
       pattern:
         spec:
           template:
             spec:
               containers:
               - name: "*"
                 # Check allowed registries
                 image: "*/nirmata/* | https://private.registry.io/*"

How Kyverno Works for Policy Management

Kyverno installs itself as an admission controller, which receives webhook events for all API object changes. Kubernetes supports two special dynamic admission controllers which are designed to allow extensibility via tools like Kyverno, the MutatingAdmissionWebhook and the ValidatingAdmissionWebhook. As the names imply, controllers of these types can change and validate API objects.

Get Started with Kyverno

Learn more about Kyverno, explore its extensive policy library, or join the Kyverno Slack community

If you’re looking for the best out-of-the-box experience, consider Nirmata Policy Manager, or better yet, start a free trial.

If you have further questions before initiating with Kyverno, you can contact us here to get answers.