Kyverno is an open source Kubernetes native policy engine. In this post, I will discuss why policy management is important for enterprise Kubernetes, and describe what Kyverno can do for you.
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 policy management is becoming increasingly important for enterprise Kubernetes.
Being 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.
Existing solutions for Kubernetes policy management were initially designed for other use cases and then fitted into Kubernetes. Our work with customers has led us to learn that policy management is important to Kubernetes’ success within enterprises, and our customers wanted a simpler and more Kubernetes friendly way of defining and managing policies.
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.
Kyverno Validates configurations
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/*"
Kyverno Mutates Configurations
Kyverno supports two different ways to mutate configurations. The first approach is to use a JSON Patch which provides a precise way to make changes to a JSON (or YAML) document.
Here is an example of a policy that adds a label to a deployment:
apiVersion : kyverno.io/v1alpha1 kind : Policy metadata : name : policy-deployment spec : rules: - name: patch-add-label resource: kinds : - Deployment mutate: patches: - path: /metadata/labels/isMutated op: add value: "true"
The other way to mutate resources is to use an overlay with conditionals that describes the desired state. Here is a policy that checks if an image tag ends with “latest” and changes the imagePullPolicy to Always:
apiVersion: kyverno.io/v1alpha1 kind: Policy metadata: name: set-image-pull-policy spec: rules: - name: set-image-pull-policy resource: kinds: - Deployment mutate: overlay: spec: template: spec: containers: # if the image tag is latest, set the imagePullPolicy to Always - (image): "*:latest" imagePullPolicy: "Always"
Kyverno Generates Configurations
The final type of policy rule generates new configurations, when a new Kubernetes namespace is created in the cluster. This is useful to set defaults for the namespace, such as a default Kubernetes NetworkPolicy that is generated for all namespaces by the policy below:
apiVersion: kyverno.io/v1alpha1 kind: Policy metadata: name: "default" spec: rules: - name: "deny-all-traffic" resource: kinds: - Namespace name: "*" generate: kind: NetworkPolicy name: deny-all-traffic data: spec: podSelector: matchLabels: {} matchExpressions: [] policyTypes: [] metadata: annotations: {} labels: policyname: "default"
How Kyverno works with Kubernetes
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.
Learn More about Kyverno & Kubernetes
Kyverno Overview and Demo
This online recording provides an overview of how Kyverno works with detailed examples:
Press on Kyverno
Here is a article by The NewStack on Kyverno:
https://thenewstack.io/kyverno-kubernetes-configuration-via-policy/
Kyverno GitHub Repository
The Kyverno GitHub repository is the best place to collaborate, ask questions, and get detailed information on the project. Kyverno is easy to install and try in your Kubernetes cluster! The complete documentation is available on our GitHub repository at:
https://github.com/nirmata/kyverno/.
We would love to hear your thoughts on Kyverno, and what use cases you would like to see supported.
Enabling a Cloud-Native Experience for Developers with Nutanix and Nirmata | nirmata
October 8, 2019 at 4:53 am[…] Policy Management – Consistent management of policies for your cluster configuration, application configuration, access, network policy, security policy, resources, across ALL clusters. Recently, Nirmata open-sourced its Kubernetes native policy management engine – Kyverno. […]
Provisioning and Securing Bottlerocket OS-Based Amazon EKS Clusters Using Nirmata Kubernetes Platform - CloudPro Exam Prep
November 16, 2021 at 2:00 am[…] practices, and standardization. The solution to address this challenge is a policy engine such as Kyverno, which uses policies to validate configurations for best practices and security compliance, and […]
The Cost Governance of Cloud-Native Workloads Using Kyverno & Kubecost
April 6, 2022 at 4:39 am[…] is an open-source Kubernetes-native policy engine that runs as an admission controller and can validate, mutate, and generate any configuration data […]
Cloud-Native Workloads Using Kyverno and Kubecost - DZone Cloud
April 16, 2022 at 2:58 pm[…] is an open-source Kubernetes-native policy engine that runs as an admission controller and might validate, mutate, and generate any configuration […]
Cloud-Native Workloads Using Kyverno and Kubecost - DZone Cloud - n-cryptech
April 16, 2022 at 3:30 pm[…] is an open-source Kubernetes-native policy engine that runs as an admission controller and can validate, mutate, and generate any configuration data […]
Cloud-Native Workloads Using Kyverno and Kubecost – Tech news
April 16, 2022 at 4:11 pm[…] is an open-source Kubernetes-native policy engine that runs as an admission controller and can validate, mutate, and generate any configuration data […]
Cloud-Native Workloads Using Kyverno and Kubecost - Briskspace
April 16, 2022 at 4:30 pm[…] is an open-source Kubernetes-native policy engine that runs as an admission controller and may validate, mutate, and generate any configuration […]
Cloud-Native Workloads Using Kyverno and Kubecost - eStraitsTimes
April 16, 2022 at 7:08 pm[…] is an open-source Kubernetes-native policy engine that runs as an admission controller and can validate, mutate, and generate any configuration data […]