At Nirmata, I work with a number of enterprise customers on their adoption of Kyverno and Nirmata policy and governance solutions. As someone who is constantly engaged with the community and customers, I often would get asked about the different Kyverno features in each version. However, with each update came a large set of changes, making it difficult to convey across. I started tracking this data, and thought it would be great to share!
The overall goal of this blog is to simplify that by summarizing all the updates that have gone into Kyverno since v1.6 and showcasing how it has evolved over time. With every version came several new features and enhancements that further established Kyverno as the de facto policy engine for Kubernetes.
The inception of many of Kyverno’s capabilities has come from listening to the community and its adopters, prioritizing their needs and wants. Let’s take a look at everything that has gone into Kyverno since v1.6 to its most recent release v1.10!
Kyverno Version 1.6
Key Features Added:
Image Verification beta: With support for annotations, keyless, KMS, in-toto annotations, and several other enhancements, the Sigstore Cosign based image verification policy rule is now in beta.
OCI Image Config: You can now use image configuration data in Kyverno policies! This allows checks for labels, volume mounts, and other data used to build the container image.
New JMESPath operators and filters: Several new operators and custom functions to make it easier to process policy data.
- Significant improvement in memory usage by reducing the use of informers.
- Improved dynamic webhook management, allowing more control in managing policy exclusions.
Kyverno Version 1.7
Key Features Added:
Mutation and Generation for Existing Resources: Kyverno will be able to perform the same type of mutations on resources that already exist in addition to still giving you the option of applying mutations during admission controls, upon item creation and update. Additionally, it’ll allow you to update your Kyverno policy and have mutations performed once again.
Better GitOps Support: Automatically-generated rules will no longer be written to the spec portion of a policy but will be computed and stored internally in Kyverno. This change will allow Kyverno to play much nicer with your GitOps tool of choice.
Enhancing Software Supply Chain Security with Image Verification: A slew of enhancements for image verification including, multi-attestor support using keys, certificates, and keyless signing with AND/OR groups, global tag-to-digest and digest enforcement, independent of signing, global signing enforcement (e.g. “all images must be signed”).
Helm Installation: Helm installs will provide guidance on how Kyverno handles cluster/node failure scenarios. Helm install will produce a message pointing you to the documentation which explains the trade-off between security and operability and how to decide which is best for you based on your needs, requirements, and way of operating.
- Validate rules received some nice updates to context variables in that now in-line variables are supported.
- Foreach rules can now iterate over a simple array of strings rather than needing to be a full object.
- Two new JMESPath filters called items and objects_from_lists which allow more manipulation of object type data.
- Kyverno CLI now has the ability to test policies that contain subjects, users, and groups.
- Twenty new policies have been added including many for ecosystem tools like ArgoCD, Flux, Kasten K10 by Veeam, and others.
Kyverno Version 1.8
Key Features Added:
Pod Security Admission Integration: Kyverno has a new validate subrule called podSecurity which internally uses the same libraries as Pod Security Admission but allows for much simpler implementation of those standards while offering flexible exemptions not found in Pod Security Admission.
YAML Manifest Verification: Support for Sigstore’s manifest project was added. With this integration, Kyverno is now additionally able to verify signatures on Kubernetes YAML manifests to ensure, like container images, that they haven’t been tampered with. Once a manifest has been signed with a private key of a user’s choosing, a new Kyverno policy may be written which verifies the signature and compares the signed (original) manifest contents with the current contents.
Cloning Multiple Resources: When provisioning a new Namespace, a variety of resources are required before handing that over. For example, Secrets, ConfigMaps, Custom Resources, and others are commonly required. This can now be done by allowing a single generate rule to define, in a selective manner, and clone multiple resources from the same source Namespace.
GitOps-Friendly Rule Auto-Generation Is Here To Stay: This feature is on by default and no feature flags are required, allowing users of popular GitOps tools like Flux and ArgoCD to deploy Kyverno policies through their tooling without having to slightly adapt their definitions to account for these changes.
- OpenTelemetry support was added for those who want an alternative to Prometheus.
- The CLI now supports testing of generate policies joining long-time support for validate and mutate rule testing.
- New JMESPath filters called random and x509_decode were added.
- The reporting system received a total overhaul which makes it lighter, faster, and more reliable.
- New schema version v2beta1 was introduced.
- Almost forty new policies have been added to the sample policy library.
Closing over 250 issues, Kyverno 1.8 was huge not just in terms of features and functionality but also in optimizations, performance, and other improvements required in strict or high-scale environments. And in addition to those, a tremendous amount of work went into refactoring and other housekeeping items that make Kyverno cleaner and more efficient. This only covered some of the new features and enhancements that went into 1.8. For the full list please reference: https://github.com/kyverno/kyverno/releases/tag/v1.8.0.
Kyverno Version 1.9
Key Features Added:
Policy Exceptions: A new type of policy and Custom Resource in Kyverno 1.9 which allows you to create an exception to any existing Kyverno policy in a way that is decoupled from the policy itself and so doesn’t involve modifying the policy.
Cleanup Policies: Brings the all-familiar match and exclude capabilities with the powerful expressions and JMESPath filtering system together with a scheduler which allows you to very granularly select and filter resources you want removed in your cluster based on a recurring schedule.
Distributed Tracing: With distributed tracing instrumented in Kyverno, you can see every rule and even every external call (in the case of OCI registry lookups) Kyverno is making and how long each span took. This is super helpful not just for visibility but also a troubleshooting and even auditability standpoint. With traces in hand sent to your collector, you can see the rules that matched the resource and were processed so you know everything is working properly.
Extended Support for Subresources: With this enhanced support, you can now easily match on the precise subresource you want (even using wildcards) and Kyverno will figure it out.
ConfigMap Caching: Kyverno can now cache the ConfigMaps you need for policy decisions simply by assigning the label cache.kyverno.io/enabled: “true” to any ConfigMap and Kyverno will automatically cache it for you.
- Nested foreach loops which are great especially for processing complex nested objects like arrays within arrays.
- There are eleven new JMESPath filters specifically for working with time.
- Pod controller rule auto-generation – added support for ReplicaSet and ReplicationController.
- The Kyverno CLI now has experimental support for uploading and downloading Kyverno policies as OCI artifacts.
- Kyverno artifacts now generates and attests to SLSA provenance which anyone on their end can publicly verify.
- More Kyverno policies were added, including mapping GateKeeper policies to Kyverno policies.
Kyverno Version 1.10
Key Features Added:
Increased Scalability with Service Decomposition: The 4 major capabilities of Kyverno have been broken out into separate deployments allowing you to switch on or off the ones you want. Since Kyverno is now decomposed into separate controllers, each controller can be scaled independently: Admission Controller, Reports Controller, Background Controller, Cleanup Controller
Extensibility via External Service Calls: Ability to make calls to services other than the Kubernetes API server – allows performing GET and POST requests against another service in the cluster along with specifying a certificate authority bundle for establishing trust against HTTPS servers.
Software Supply Chain Security with CNCF Notary: Added a new type field to verifyImages rules allowing you to specify the signatory used, either Notary or Cosign.
Generate Rule Refactoring: Significant overhaul on generate rules to add new functionality, fix issues, and improve the user experience. One of the new features in generate rules is to allow the triggering resource to share the same synchronization life cycle as the generated resource.
- Operations can now be specified directly in match and exclude blocks obviating the need for preconditions.
- Policy Exceptions have been enhanced to add support for background scanning.
- Several enhancements to Policy Reports.
- Three new JMESPath filters, image_normalize(), trim_prefix(), and to_boolean().
Kyverno 1.10 is the biggest release to date with close to 500 PRs, including tons of new features and a number of fixes/improvements that affect Kyverno’s performance and scalability. For a full list of everything that went into this version please reference: https://github.com/kyverno/kyverno/releases/tag/v1.10.0.
Kyverno continues to grow exponentially with the help of its community and maintainers. Through the years Kyverno has evolved to fill in the gaps that we felt weren’t addressed by other tools.
The project metrics speak for themselves. With adoption across multiple industry verticals, Kyverno has proven itself to be stable and reliable.
The choices made by the Kyverno community to focus on user experience for policy writing, stability, and scale are further validated through the continual adoption from several large enterprises and ecosystem partners:
The upcoming 1.11 release of Kyverno promises to pack even more power. If you want to learn more about Kyverno, what is coming in 1.11, and how our enterprise customers are using Policy as Code to secure and automate Kubernetes, feel free to reach out to me or book some time here! https://info.nirmatadev.wpengine.com/meetings/luismartinez/30min
Try Nirmata for free at: https://try.nirmata.io/