Kyverno v1.6.0: More Kubernetes Security and Governance Use Cases Through Policy

Kyverno v1.6.0: More Kubernetes Security and Governance Use Cases Through Policy

We are excited to announce Kyverno’s latest version v1.6.0! This is the first feature release since KubeCon NA 2021, where we announced the release of version 1.5.0.

In this article, I will introduce Kyverno’s version 1.6.0 and highlight new features as well as enhancements made in this release.

New Features

The Image Verification Policy

Verify image signatures

In Kyverno 1.5.0, we introduced an alpha feature for a new type of rule to verify image signatures using sigstore Cosign. The rule matches an image reference (wildcards are supported) and specifies a public key to be used to verify the signed image or attestations.

kind: ClusterPolicy
 name: check-image
 validationFailureAction: enforce
 background: false
 webhookTimeoutSeconds: 30
 failurePolicy: Fail
   - name: check-image
           - Pod
     - image: "*"
       key: |-
         -----BEGIN PUBLIC KEY-----
         -----END PUBLIC KEY-----

In 1.6, this rule type was extended with additional features!

Cosign keyless signing & verification

Cosign can be used to sign the container image with “keyless” signing, where a temporary keypair is generated to sign the image, and deleted after recording the signing in an immutable transparency log. The temporary certificate uses an OIDC identifier as the subject. 

To verify the image with a Kyvermo policy, you can  provide the root CA or the address of the transparency log, so that Kyverno can validate the image.

For details on this feature, here is a demo video

Sign and verify image attestations

In Kyverno 1.6, you can now use Kyverno policies to verify image attestations.  An attestation is verifiable metadata and other information produced for the image. For example, this can be a vulnerability scan report, or build system information.

These attestations use a tool called in-toto attestation that has standard attestation format. You can sign these attestations and attach to the image and store it in the registry. Kyverno by default if you have such policies configured, it will look up from that registry and get and decode all the attestation statements.

The background scan is also enabled for this type of look so you can have a policy report based on the configured image verify policy.

Built-in image data to validate image configs

Kyverno V1.6.0 has a new feature to fetchimage configuration data that can be used to validate  image properties and to have the ability to use this additional config data to create policies. These image data include; image url, authors, source, licenses, volumes, size, labels. A more compiled list of these examples can be found here.

Some real world use cases:

  • we create images with manifest annotations as defined by Pre-defined annotation keys.  
  • Validate the values of some of those keys like image url, source, declared licenses for the image and the base image for the image.
  • Validate the size of the image: To prevent images which are larger than a specific size (the manifest contains the output size of the layers without actually downloading them). 
  • Validate that the image is CUDA based when gpu resources are used. 
  • Mutate the output resource based on the image config, for eg set a default non root user for the containers in case it is set to root. 
  • Mutate the image tag to the resolved tag
  •  Being able to validate the labels set in an image, for eg. the buildpacks ( ) used to construct an image
  • Allows custom resources (not just pods/deployments etc.) and get the image references from arbitrary parts of the resource.
  • Audit results in policy reports 

Kyverno policy reports are Kubernetes resources that provide information about policy results, including violations. Kyverno creates policy reports for each Namespace and a single cluster-level report for cluster resources. These policy reports now support imageVerify in Kyverno 1.6.0


Improved Performance

In previous releases, the memory usage grows leaving you with a  large scale of  clusters (informers).  That is because we used the dynamic informers in the background controller and by default, Kubernetes informers  maintain memory cache. So when you have thousands of load resources in a cluster, Kyverno memory grows.

In V1.6.0, Kyverno moved away from dynamic informers in the policy controller. It has been verified that the memory usage was reduced from ~400 Mi to ~200 Mi with 80 Cronjobs & 10K Configmaps scheduled in the cluster. This is to avoid the Kyverno memory to grow particularly when you are running it on a large scale cluster.


Prior to V1.6.0,  Kyverno users encountered difficulties in shutting down and restarting clusters without properly terminating Kyverno. This often leads to  admission webhook configurations blocking workload  resources from recovering. In this latest release, we have enabled the  “namespaceSelector” by default  for dynamic namespaces exclusion.

You can also  configure the failure policy for webhook configurations per Kyverno policy. For instance, If you set the failure policy to Fail , in that case if the webhook is not responding or if there is an error of the initials webhook, Kubernetes will reject the admission request. Set failure policy to Ignore let you bypass the webhook failures.

Also, the dynamic webhook feature which was introduced in v1.5.0. This is something Kyverno will automatically manage the webhook configuration based on the installed policy. That means, if you don’t have any policy in your cluster, Kyverno will not impact any of the cluster workloads or resources.

Namespace Scoped FailureAction


Version 1.6.0 now has an override ability for the Failure action. This allows you to make exceptions for Kubernetes namespaces to either enforce  or audit policy violations.

New Operators

Kyverno v1.6.0 has several new operators  that make it a lot easier for some new policies to be written. These operators are useful in preconditions and deny.conditions. There are four new types of operators;

  • AnyIn
  • AllIn (replaces In)
  • AnyNotIn (replaces NotIn)
  • AllNotIn

These operators help you unlock new possibilities or either writing new types of policies or making existing policies better. 

  • Support for ranges

Kyverno now also has support for integrated ranges. Also, some of the existing operators like GreaterThan (etc) now support duration and semver (not all 1.6)

New JMESPath Filters

Adding to the existing JMEspath filters, we have also added a whole bunch of new ones that allow you to carry out common operations like; 

  • truncate()
  • semver_compare()
  • path_canonicalize()
  • time_since()
  • modulo()
  • multiply()
  • divide()
  • add()
  • subtract()
  • parse_yaml()
  • parse_json()
  • pattern_match()

foreach enhancements

The Foreach is a Kyverno ability that allows you to loop over objects in an array.  Kyverno v1.6.0, Supports JSON 6902 patches that permits you to do things like specific removes.

This version also has the new elementIndex variable, that allows you to refer to what the specific indexed being operated on. This works hand in hand with the JSON 6902 patch. In order to operate outside a resource, the  New elementScopefield allows you to pick and refer to any other field that may be existing in that resource. This version also permits contexts inside loops (like image variables).

PSS Policies Updates:

Kyverno 1.6.0 also consists of updates that have been made to the PSS policies. 


To conclude, Kyverno now records over 100 sample policies that are readily available to download and use. This release focused on adding more features that solve more use cases through policies giving you an easy experience.  Test drive this new release and please share your feedback with the team. You can reach out to the Kyverno team on the #kyverno Slack channel or mailing list. Learn lots more about Kyverno, its features and benefits, by visiting this page.

More resource: What’s new with Kyverno via CNCF live stream

Runtime Security for Kubernetes
Software Supply Chain Security on Amazon EKS clusters using Amazon ECR, Kyverno, and Cosign
No Comments

Post a Comment