Kyverno – Blog posts about Kyverno releases

Blog: Kyverno 1.10 Released

Tue, 30 May 2023 00:00:00 +0000

The Kyverno team are proud to announce the release of Kyverno 1.10, a minor release in terms of version number but a major release in every other regard. With around four months in the making and after four pre-releases and nearly 500 pull requests merged, Kyverno 1.10 is one of the largest releases in the history of the project and features a ton of new and highly-requested features and a staggering number of fixes and improvements. It also brings with it some breaking changes so please read thoroughly. We can’t wait for you to see what’s inside so let’s get started!

Key New Features of Kyverno 1.10

Kyverno 1.10 contains several new and significant features including decomposing Kyverno into smaller pieces, external service calls, Notary v2 support, and a major revamp of generate rules.

Increased Scalability with Service Decomposition

In previous versions of Kyverno, everything except the cleanup controller (introduced in 1.9) was packaged in a single container. This made sense in the early days, but as Kyverno began to grow in capability and complexity, the single-deployment model just wasn’t going to cut it. Users also wanted a way to only install what they needed and not get everything else that came along with it. Beginning in Kyverno 1.10, the major capabilities of Kyverno have been broken out into separate deployments allowing you to switch on or off the ones you want. What this looks like is shown below.

The four major components of Kyverno and their primary functions are as follows:

Admission Controller: The heart of Kyverno, the Admission Controller receives and processes webhook requests from the Kubernetes API server and is responsible for validate, mutate, and verifyImages rules along with Policy Exceptions. It also performs most of the validations on policies themselves. This is the only required component of Kyverno which must be installed.
Reports Controller: Responsible for processing of Kyverno’s Policy Reports including performing background reporting scans.
Background Controller: Not to be confused with background scans, the Background Controller handles all the generate rules and mutate rules when they impact existing resources (which all happen in the background).
Cleanup Controller: Takes care of all the cleanup tasks according to cleanup policies.

Because Kyverno is now decomposed into separate controllers, each controller can be scaled independently although they all don’t necessarily handle it differently. We recommend reading the High Availability page for more details on the internals of these controllers and how scale and availability are handled per controller.

Extensibility via External Service Calls

Kyverno is already able to gather data from external sources as a factor in its policy-making decisions, for example from the Kubernetes API, OCI image registries, and ConfigMaps. However, one of the most requested features has been the ability for it to make calls to services other than the Kubernetes API server for the same reasons. We’re happy to say that as of Kyverno 1.10, this feature now exists! It is new and a bit limited at this point so we can get an understanding of how folks intend to use it, but it 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. A sample of what this looks like is shown below.

 1apiVersion: kyverno.io/v1
 2kind: ClusterPolicy
 3metadata:
 4 name: check-namespaces 
 5spec:
 6 validationFailureAction: Enforce
 7 rules:
 8 - name: call-extension
 9 match:
10 any:
11 - resources:
12 kinds:
13 - ConfigMap
14 context:
15 - name: result
16 apiCall:
17 method: POST
18 data:
19 - key: somekey
20 value: "{{ somevariable }}"
21 service:
22 url: http://sample.myservice/someendpoint
23 caBundle: |-
24 -----BEGIN CERTIFICATE-----
25 <snip>
26 -----END CERTIFICATE----- 
27 validate:
28 message: "This shall not pass due to item {{ fookey}}"
29 deny:
30 conditions:
31 all:
32 - key: "{{ result.allowed }}"
33 operator: Equals
34 value: false

And, by the way, in addition to POST calls to external services, we’ve also enhanced the existing apiCall context variable to be able to POST to the Kubernetes API making it possible to do things like pass a SubjectAccessReview which will make permissions assessments much easier.

Software Supply Chain Security with CNCF Notary

The Notary project is another project, like Sigstore, aiming to solve software supply chain security through OCI image signing. Notary is currently in its second version and differentiates itself from Sigstore by using OCI artifacts to store image signatures. Although Kyverno has had support for verifying signatures and attestations from Sigstore’s Cosign project for a while now, we wanted to add support for Notary so that no matter what technology you use to sign your images, Kyverno will be there for you.

Starting in Kyverno 1.10, we’ve added a new type field to verifyImages rules allowing you to specify the signatory used, either Notary or Cosign. An example of what this looks like is shown below.

 1apiVersion: kyverno.io/v2beta1
 2kind: ClusterPolicy
 3metadata:
 4 name: check-image-notary
 5spec:
 6 validationFailureAction: Enforce
 7 webhookTimeoutSeconds: 30
 8 failurePolicy: Fail 
 9 rules:
10 - name: verify-signature-notary
11 match:
12 any:
13 - resources:
14 kinds:
15 - Pod
16 verifyImages:
17 - type: Notary
18 imageReferences:
19 - "mytest.azurecr.io/user/net-monitor:v1"
20 attestors:
21 - count: 1
22 entries:
23 - certificates:
24 cert: |-
25 -----BEGIN CERTIFICATE-----
26 <snip>
27 -----END CERTIFICATE-----

While this addition supports simple Notary v2 verification, if needing to call an external service when using an extension, the external service call feature as shown earlier can be used.

Generate Rule Refactoring

Even though generate rules have been a cornerstone of Kyverno for a while now, we did a significant overhaul on them to add new functionality, fix issues, improve the user experience, and just in general give it a major face lift. Specifically, one of the new features in generate rules which has been a frequent request is to allow the triggering resource to share the same synchronize life cycle as the generated resource. Users told us they want to be able to remove or change a trigger while sync is on and have that influence the resource that trigger was responsible for generating. This is now a reality in Kyverno 1.10 and will help in multitenancy use cases where generate rules are so frequently employed.

We didn’t stop there, though, we also added new features like triggering on DELETE requests, triggering on subresources, and performing permissions checks up front when the generate rule is created, helping to avoid failures down the line in case you forgot to add them. These features and many more can be found inside Kyverno 1.10 when using generate rules. We also had to make some tough decisions that lead to a couple breaking changes, so please read the release notes carefully if you’re a user of generate rules. And although we’ll talk about upgrades below, we strongly suggest removing and then reintroducing them in your cluster (or at least in a test cluster somewhere) to allow Kyverno to validate the new restrictions put into effect in 1.10.

Other Additions and Enhancements

There are loads of other additions and enhancements to be found in Kyverno 1.10 and we simply can’t cover them all, but here are the most notable ones.

Operations can now be specified directly in match and exclude blocks obviating the need for preconditions. This enhancement can simplify your rules by moving that condition to match on CREATE, for example, up into the match block. Specifying operations like this is also a requirement if you want to generate something based upon a DELETE operation.

1match:
2 any:
3 - resources:
4 kinds:
5 - Service
6 operations:
7 - CREATE

Policy Exceptions have been enhanced in 1.10 to add support for background scanning, useful when you consume a Policy Report and want to see that fail result to go away, and wildcards in the ruleNames[] field. The latter will assist when you might have several rules in a policy which begin with the same prefix.

A number of significant enhancements were made to Policy Reports in Kyverno 1.10 which dramatically improve performance, reduce time to aggregate reports, and lower resource consumption. Another enhancement some users may rejoice in hearing is that background scans will now, by default (but configurable, of course) consider Kyverno’s resource filters when producing reports. So if you’ve excluded a Namespace in the resource filter, by default you won’t see any reports for it either when coming from background scans.

Context variables are now lazily evaluated (JIT) which means no more failed rules when preconditions don’t pass. Variables are often used in conditions and so they will follow the same circuit-breaking mechanisms already in place for those conditions. This should also have the benefit of reducing API calls in rules where they may not always be needed.

Speaking of conditions, there’s now a new message field that’s available for use in conditions everywhere they’re used throughout Kyverno which will allow you to append the contents of that field in the message response returned by Kyverno. This is especially handy in verifyImages rules where the reason why an attestation verification failed can be narrowed down to the exact condition. And if there are multiple, they’ll be appended to each other. Very handy indeed.

Kyverno 1.10 has three new JMESPath filters, image_normalize(), trim_prefix(), and to_boolean() in addition to some enhancements to existing filters. A couple of those enhancements to call out are the sum() filter can now sum quantities like memory making it valuable for adding up all the memory requests in a Pod to figure out whether it should be allowed or not. And the x509_decode() filter now supports decoding of Certificate Signing Requests so you can apply additional security checks if you use that API.

Lastly, the documentation and policy library were greatly refreshed and improved as of this release. Not just that, but all Kyverno policies in the library can now be found on Artifact Hub making Kyverno policies presently the fourth largest artifact type.

Potentially Breaking Changes

As we hope you’ve seen, Kyverno 1.10 has some truly amazing features and enhancements in store for you, but making all this happen plus the hundreds of fixes we didn’t cover here meant we had to make some important decisions. We’d like to make you aware of these breaking changes up front so there are no surprises.

First, due to the decomposition efforts, the Kyverno Helm chart had to basically be rewritten. This is reflected in a major version number increment from 2 to 3. As such, there is no direct upgrade path when coming from v2 of the chart and attempts to do so will be blocked by default. We’ve written up a Helm upgrade and migration guide here and we strongly recommend you give that a good read. Although we also publish a YAML manifest as part of each release, there again a direct upgrade is not supported. In short, we recommend a backup-uninstall-reinstall-restore method when approaching this release, but the write-up has more details.

For rules which matched on certain types of subresources like PodExecOptions, you’ll need to move to the canonical format of them such as Pod/exec. A simple change to make, and Kyverno will let you know if you try to create it the other way.

And, finally, because of the number of issues we sorted regarding generate rules in this release, we had to put a few more guardrails in place to ensure the correct user experience was being met. Some fields now no longer support defining variables, some others may be immutable after rule creation, and a few fields will now be required whereas they previously were not. The latter we’ve tried to limit to situations in which policies are newly seen and not which pre-exist in the cluster.

For these breaking changes, and others, please carefully read the extensive and (yes, sorry) lengthy release notes here.

Closing

Kyverno 1.10 is quite the loaded release as you can probably see. After about four months and close to 500 PRs, there were a tremendous number of changes from the Kyverno community. And if you were one of the many, many contributors who pitched in to make this release a reality, a hearty THANK YOU for all your work! Hopefully what you’ve seen makes you excited to try out 1.10 for yourself. Come engage with us in the Kyverno channel on Kubernetes Slack, attend one of our community meetings, or just catch us on Twitter.

And if you’re already a Kyverno adopter, sign up to be an official adopter by updating the Adopters form here.

Blog: Kyverno 1.9 Released

Wed, 01 Feb 2023 00:00:00 +0000

With the ringing in of the new year the Kyverno team is proud to announce the release of Kyverno 1.9.0, a release that we’ve been working hard on over the past several months and which is full of massive new features include TWO brand new rule types, several community-requested enhancements, and loads of fixes and improvements. Without any further ado, let’s dive right in and show you what’s in the bag.

Key New Features of Kyverno 1.9

Policy Exceptions

Something we’ve heard for a while now from the community was that they love the ease with which Kyverno can select resources (and, really, just ease of use in general) for action by policies but that this was limiting in certain ways. It may not be scalable to modify every policy with the same exclusions, and, secondarily, in real-world ops scenarios everyone has special exceptions that need careful handling. So we’re excited to show off our new PolicyExceptions in 1.9!

A PolicyException is 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 which is decoupled from the policy itself and so doesn’t involve modifying the policy.

Here’s what it would look like to allow a special exception to one of the Pod Security Standard policies but only for a very specific resource named important-tool.

 1apiVersion: kyverno.io/v2alpha1
 2kind: PolicyException
 3metadata:
 4 name: delta-exception
 5 namespace: delta
 6spec:
 7 exceptions:
 8 - policyName: disallow-host-namespaces
 9 ruleNames:
10 - host-namespaces
11 - autogen-host-namespaces
12 match:
13 any:
14 - resources:
15 kinds:
16 - Pod
17 - Deployment
18 namespaces:
19 - delta
20 names:
21 - important-tool*

Once a PolicyException is created, a resource which is selected by the exception and also applies to the policy and rule combo named in the exception will be allowed to circumvent the policy. As shown, it’ll be quite useful, we think, for users who want those one-time exceptions to validate rules which are in Enforce mode although it works for other situations and rules as well. Access to creating PolicyExceptions can be controlled through a combination of Kubernetes RBAC, your own GitOps review processes, YAML signing for integrity and tamper-prevention checks, and even Kyverno validate policies.

Cleanup Policies

With Kyverno’s unique generation rule, which remains one of its most popular abilities and is beloved by ops teams everywhere, it has proven that Kyverno is far more capable than a simple admission controller which can only deliver “yes” or “no” responses. Generation, especially when combined with validation and mutation, unlocks tremendous power and turns Kyverno into a true tool of automation. That was a great first step, but we knew we could do more. We heard there was a piece missing from the story and that piece was the ability to delete as well as create. Well, we’re really happy to say that as of Kyverno 1.9, our second new policy type will allow you to do just that: cleanup resources on a scheduled basis.

A Kyverno CleanupPolicy 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. Just take a look at the below sample.

 1apiVersion: kyverno.io/v2alpha1
 2kind: ClusterCleanupPolicy
 3metadata:
 4 name: clean-nekkid-pods
 5 annotations:
 6 pod-policies.kyverno.io/autogen-controllers: none
 7spec:
 8 match:
 9 any:
10 - resources:
11 kinds:
12 - Pod
13 conditions:
14 all:
15 - key: "{{ target.metadata.ownerReferences[] || `[]` }}"
16 operator: Equals
17 value: []
18 schedule: "0 0 * * *"

Here is a ClusterCleanupPolicy which, as you might have guessed, applies cluster-wide, and which will find and remove Pods with no ownerReferences every day at midnight. Cleanup policies like these can be super helpful to keep clutter to a minimum and fit nicely into existing automation workflows.

A policy-based approach is only the first step, and in the second phase we intend on implementing automated cleanup based on a reserved label or annotation assigned to resources.

Distributed Tracing

In the 1.8 release, we added OpenTelemetry support, but in this release we wanted to one-up ourselves and add in more observability to provide insights on exactly what Kyverno is doing to your resources. So in 1.9, we’ve added full support for 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 from a visibility but also a troubleshooting and even auditability standpoint. With traces in hand sent to your collector, you can see the rules which matched the resource and were processed so you know everything is working properly.

Extended Support for Subresources

Kyverno has had support for some subresources for a few releases now (ephemeral containers have been supported since 1.7), but there were still gaps. Specifically, Kyverno had problems with the Scale subresource, which can be tricky to deal with, as well as mutations to the Status subresource. This meant that a couple real-world use cases that have come up simply weren’t possible to implement in Kyverno policies. With Kyverno 1.9, that should be a thing of the past and most, if not all, subresources can be handled quite well.

With this enhanced support, you can now easily match on the precise subresource you want (even using wildcards) and Kyverno will figure it out. For example, advertising extended resources to Kubernetes nodes is important for use cases like GPUs and FPGAs, and with a Kyverno mutate rule targeted at Node/status, it’s now incredibly simple and doesn’t require any custom webhooks. The below policy will add the example.com/dongle resource to new Nodes brought up in the cluster.

 1apiVersion: kyverno.io/v1
 2kind: ClusterPolicy
 3metadata:
 4 name: advertise-resource
 5spec:
 6 background: false
 7 rules:
 8 - name: advertise-dongle
 9 match:
10 any:
11 - resources:
12 kinds:
13 - Node/status
14 mutate:
15 patchStrategicMerge:
16 status:
17 capacity:
18 example.com/dongle: 2

ConfigMap Caching

ConfigMaps are a common source of data not just to Pods but to Kyverno policies as well. Kyverno has long had support for dynamic lookups from ConfigMaps without requiring any pre-syncing, and in most use cases this was fine. But as more users flocked to Kyverno with ever larger clusters, these additional API calls produced some unwanted overhead. Starting in Kyverno 1.9, if you would like Kyverno to cache the ConfigMaps you need for policy decisions, simply assign the label cache.kyverno.io/enabled: "true" to any ConfigMap and Kyverno will automatically cache it for you. Nothing else you need to do.

Other Additions and Enhancements

Some other cool features and status updates we’re proud to share include new JSON logging format and the ability to dump out the full AdmissionReview contents the API server sends to Kyverno. The latter has been a common request from the community and should help in those situations where you’re not quite sure how to write a certain policy. Both require setting a new container flag so check out the docs.

Kyverno now supports nested foreach loops which are great especially for mutation use cases where you need tactical modifications or removals from complex nested objects like arrays within arrays.

There are eleven new JMESPath filters specifically for working with time. These filters include things like getting current time, converting it from different formats, and even translating the time to a Cron expression. These are sure to come in handy when writing policies which account for time in various ways.

Pod controller rule auto-generation, another of Kyverno’s hallmark capabilities which if you’re not familiar allows Kyverno to translate rules solely for Pods to all other major Pod controllers, added support for ReplicaSet and ReplicationController. There’s nothing policy authors need to do and Kyverno will now add these two resources into the auto-gen rules for you.

The Kyverno CLI now has experimental support for uploading and downloading Kyverno policies as OCI artifacts. This is great for storing policies alongside container images using the same, common semantics. In the future, we’re planning on doing more with this support so keep a lookout.

We’re preparing for the movement away from v1 of our policy schema which has served us well for a while now. As we go towards v2beta1, which is available in 1.9, we get rid of deprecated and obsoleted fields to make a nice and tidy policy. We ask you to start moving in the direction of v2beta1 now to make the removal process much smoother.

Kyverno 1.9 brings support for Kubernetes 1.26. Kyverno follows an N-2 support policy, and so to ensure we’re staying current, we’re now building and testing up to 1.26.

We have long been a champion of software supply chain security and insist on enacting these practices ourselves. With the 1.9 release, Kyverno now generates and attests to SLSA provenance which anyone on their end can publicly verify. We believe this and other policies by which we abide makes us adherent to SLSA Level 3 and will be working with the Open Source Security Foundation to ensure this is the case.

And last but not least, the Kyverno policy library, the largest community-driven library of any policy engine for Kubernetes, has received another large bump putting it well over the 250 mark. Included in this library update is a new table which maps Gatekeeper policies to Kyverno policies, helpful for users of both tools to see how to accomplish some common use cases in these engines.

Potentially Breaking Changes

One change we do want to make you aware of, which actually came in 1.8.3, which could be breaking is a schema modification for verifying a container image attestation. Due to some upstream changes in Sigstore’s cosign, we had to move the attestors under the attestation being verified. This necessitated a schema change which you can find in the documentation. So if you have Kyverno policies which verified image attestations, please update them to the new schema so they continue to work in 1.9.

Closing

With so many new features, enhancements, and well over 200 fixes, there’s so much to get excited about in this release. Hopefully what you’ve seen makes you excited to try out the 1.9 release and provide your feedback. Come engage with us in the Kyverno channel on Kubernetes Slack, attend one of our community meetings, or just catch us on Twitter.

Blog: Kyverno 1.8 Released

Mon, 24 Oct 2022 00:00:00 +0000

Following on the heels of the 1.7 release of Kyverno, the Kyverno team is proud to present version 1.8 which is another huge leap forward not just in terms of features and functionality but of 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 making future development (and contributions) easier, quicker, and ultimately more maintainable. We’ll walk through the largest of these features in this article.

Key New Features of Kyverno 1.8

Pod Security Integration

The successor to Kubernetes’ Pod Security Policy (PSP) is Pod Security Admission, enabled by default in 1.23 and stable now in 1.25. This new technology implements a set of standards dubbed Pod Security Standards. Pod Security Admission brings many benefits over PSPs but also some fairly important caveats. Starting in 1.8, 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. Shown below is an example of this new podSecurity rule in action which implements the entire restricted profile of the Pod Security Standards across the entire cluster.

 1apiVersion: kyverno.io/v1
 2kind: ClusterPolicy
 3metadata:
 4 name: podsecurity-restricted
 5spec:
 6 background: true
 7 validationFailureAction: audit
 8 rules:
 9 - name: restricted
10 match:
11 any:
12 - resources:
13 kinds:
14 - Pod
15 validate:
16 podSecurity:
17 level: restricted
18 version: latest

YAML Manifest Verification

Although Kyverno has integrated with Sigstore tooling for some time now, offering capabilities like container image signature verification and attestation verification, Kyverno 1.8 steps this up one notch further by bringing support for Sigstore’s manifest project. 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 comparing the signed (original) manifest contents with the current contents. Shown here is an example of such a policy which verifies the key used to sign Deployments.

 1apiVersion: kyverno.io/v1
 2kind: ClusterPolicy
 3metadata:
 4 name: verify-manifest-integrity
 5spec:
 6 validationFailureAction: audit
 7 background: true
 8 rules:
 9 - name: verify-deployment-allow-replicas
10 match:
11 any:
12 - resources:
13 kinds:
14 - Deployment
15 validate:
16 manifests:
17 attestors:
18 - count: 1
19 entries:
20 - keys:
21 publicKeys: |-
22 -----BEGIN PUBLIC KEY-----
23 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEStoX3dPCFYFD2uPgTjZOf1I5UFTa
24 1tIu7uoGoyTxJqqEq7K2aqU+vy+aK76uQ5mcllc+TymVtcLk10kcKvb3FQ==
25 -----END PUBLIC KEY----- 
26 ignoreFields:
27 - objects:
28 - kind: Deployment
29 fields:
30 - spec.replicas

Signing of manifests is a great way to bolster the security of your cluster, but it also requires some flexibility. Teams often need to change values and certain fields (in addition to Kubernetes itself needing to sometimes change them). That’s why with this new rule type there is an object where you can specify which fields to ignore when verifying those manifests. In the previous policy, it provides an exception for the replicas field of a Deployment allowing only the value of this field to deviate from what was originally signed.

Cloning Multiple Resources

One of the defining capabilities of Kyverno is its simple way of generating new Kubernetes resources as opposed to just validating or mutating them. We’ve seen tremendous adoption of this policy-based ability by software teams and users all over the place. One of the most common use cases for this generate ability is in multi-tenancy or Namespace-as-a-Service provisioning processes. But something we heard loud and clear was that users needed to clone more than just a single resource at a time. Very often, 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. In Kyverno 1.8, we’ve brought you this ability by now allowing a single generate rule to define, in a selective manner, and clone multiple resources from the same source Namespace. As you can see from the below policy, whenever a new Namespace is created, all the Secrets and ConfigMaps in the staging Namespace which have been labeled with allowedToBeClone=true will be cloned into the new Namespace.

 1apiVersion: kyverno.io/v1
 2kind: ClusterPolicy
 3metadata:
 4 name: provision-namespaces
 5spec:
 6 rules:
 7 - name: sync-secrets-configmaps
 8 match:
 9 any:
10 - resources:
11 kinds:
12 - Namespace
13 generate:
14 namespace: "{{request.object.metadata.name}}"
15 synchronize: true
16 cloneList:
17 namespace: staging
18 kinds:
19 - v1/Secret
20 - v1/ConfigMap
21 selector:
22 matchLabels:
23 allowedToBeCloned: "true"

GitOps Friendly Rule Auto-Generation Is Here To Stay

In the 1.7 release, we introduced the new concept of moving Pod rule autogeneration out of spec and into status to be more kind to our GitOps users. Now in 1.8, that 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.

Other Additions and Enhancements

Kyverno 1.8 is such a substantial release it’s hard to cover all of the features, but here are a few others to note.

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.

On the JMESPath side, we have two new filters called random and x509_decode. The random filter gives Kyverno the ability to generate random strings of data but in a fully composable and easy-to-use way. The x509_decode filter allows Kyverno to interpret PEM-encoded X509 certificates and make policy decisions based upon their contents, excellent for doing things like checking certificate subjects, expiration dates, and more.

The reporting system received a total overhaul in this release which makes it both lighter on memory, faster to generate policy reports, and more reliable.

Over time with the tremendous development velocity achieved in Kyverno, we’ve added many new fields and changed others. Kyverno 1.8 introduces a new schema version v2beta1 which is what we’ll begin using in the near future as it brings all the various rule types fully up-to-date with the latest and greatest.

And on the sample policy library, almost forty new policies have been added including implementation of best practices for common service meshes like Istio and Linkerd, CI/CD tools like Tekton, and more. This brings the total up to around 230 making Kyverno, by far, the policy engine with the largest number of samples designed to help get you running faster and easier.

Potentially Breaking Changes

A couple things of which to be aware prior to upgrading. First, the Helm chart registry URL has changed to ghcr.io/kyverno/charts/kyverno so make sure to update your Helm repositories. And second, because we’ve revamped Kyverno’s reporting and background scanning abilities, the backgroundScan container flag you might have passed previously has changed to being a true or false value, simply either activating or deactivating background scans.

Closing

Just like in previous releases, Kyverno 1.8 is a huge release closing over 250 issues. The maintainers and contributors have been hard at work for the past few months trying to bring additional value to the community, so we hope you find this release useful. As always, we love the community and hope you engage with us on any one of our outlets.