Nirmata’s Kyverno: Kubernetes Configuration Via Policy
Kubernetes-management vendor Nirmata has open sourced a project called Kyverno that enables users to validate, mutate and generate configurations through policy.
With Kyverno, cluster administrators can manage environment-specific configurations independently of workload configurations and enforce configuration best practices for their clusters.
In the enterprise, there is the cluster-operations role and several development teams that are using Kubernetes.
“With all the flexibility it provides, how do you enforce best practices for configuration management and common policies that an organization requires? Things like making sure image registries are trusted registries, making sure health checks are configured for applications, resource quotas are configured and even mutating existing configurations based on environmental settings,” said Jim Bugwadia, Nirmata founder and CEO.
For mutation, policies can be written as overlays similar to Kustomize or as a JSON Patch. Policies on validation also use an overlay-style syntax, with support for pattern matching and conditional (if-then-else) processing.
As an admission controller, it’s inspecting data coming in, and whether it matches the resource, based on the name, the type or label selectors. Then one of these rules can be used to mutate configurations, change existing configurations or validate existing settings.
Kyverno receives validating and mutating admission webhook HTTP callbacks from the kube-apiserver and enforces admission policies or rejects requests. Policy enforcement is captured using Kubernetes events. Kyverno also reports policy violations for existing resources.
Previously implemented in the management layer of Nirmata itself, the policy engine has been moved down into Kubernetes as a custom resource. It works independently of Nirmata — with kubectl or any tool you want for your CI/CD pipeline.
While folks at ChefConf 2019 recently in Seattle were discussing the role of configuration-management tools in a Kubernetes world, Bugwadia calls Kyverno the last step in the configuration-management pipeline.
While there are alternatives such as Open Policy Agent (OPA), Polaris and other tools, the Nirmata team wanted to do two things: Not just validating configuration, but being able to update and edit configurations as they’re being applied.
“You might only want one instance, but in production, you want to make sure there are multiple replicas running. Things like that, you can quickly define these policies as Kubernetes objects. It is a Kubernetes resource, it follows all the declarative management best practices, it has label selectors, wildcarding… we’re generating Kubernetes objects as policies are being enforced so the resource owner has good visibility into what’s going on,” he said.
It also wanted it to be Kubernetes-native. Other vendors created technology for other use cases, then have tried to fit it to Kubernetes, he maintains.
A policy is a set of ordered rules, each with a unique name and optional message. Each rule matches one or more resource and is of a single type (generate, mutate, validate.)
“You can check that your pod configuration has resource quotas. It can automatically change things, like storage classes based on your cluster settings; generate defaults, which is very important for security — when you create a new namespace, you want a new set of defaults. These we can generate automatically once these policies are set up,” he said.
The project’s GitHub page warns that it is still under active development and not ready for production use.
Chef and Nirmata are sponsors of The New Stack.
Feature image via Pixabay.
