We are super excited to announce the release of Kyverno 1.3.5. This release is packed with performance enhancements, critical fixes, 53 Kyverno policies, updates in Kyverno CLI and many more!

In this post, I will highlight the key features available in Release 1.3.5.  For a full list of features and improvements, please check the release notes. 

Multiple generate workers: 

Kyverno can now concurrently process multiple generate policy requests. The number of generate workers is defaulted to 10. Scaling up workers for generate controller helps reduce processing time.Users can tune the number of workers using the  flag gen-workers (Workers for generate controller).
Prior to this feature creating  100 namespaces with a single generate add networkPolicy policy will takes time  about 10 minutes. With the concurrent  worker count to 10 workers, 1 cleanup worker, 20 gr-creators, takes 127s to process these generation requests.

The gen-workers flag is used to control the behavior of Kyverno and user’s must be set in the Kyverno ConfigMap.

Example: 

 apiVersion: v1
 data:
   gen-workers: 10
 kind: ConfigMap
 metadata:
   name: init-config
   namespace: kyverno 

Updated Policy Library with flexible filtering: 

In this release, there are 53 sample policies available for validate, mutate and generate rules including pod security standards. You can now filter policies by rule types or categories. The sample policies are available at: https://kyverno.io/policies/.

Images variable:

Variables make policies more flexible by enabling references to data in the policy definition. Some supported data sources include the admission review request and external data sources like ConfigMaps and the Kubernetes API Server.

In this release , we have added new predefined variable called images.

Kyverno parses each container image from the admission review request and builds a map with  registry, name, tag, digest of the image.

So If you have a pod using any image, Kyverno extracts the image properties to the images map and makes it possible for the policy rules to  consume these variables

Basically it’s a new filter which filters the resource based on the namespace in which it is created and filters basically on the namespace labels.

Here is an example:

 {
   "containers": {
     "tomcat": {
       "registry": "https://ghcr.io",
       "name": "tomcat",
       "tag": "9"
     }
   },
   "initContainers": {
     "vault": {
       "registry": "https://ghcr.io",
       "name": "vault",
       "tag": "v3"
     }
   }
 } 

Whenever an admission review request has containers or initContainers defined, the images variable can be referenced as shown in the examples 

Reference the image properties of container tomcat:

1. Registry URL: {{images.containers.tomcat.registry}}
2. Image name: {{images.containers.tomcat.name}}
3. Image tag: {{images.containers.tomcat.tag}}
4. Digest: {{images.containers.tomcat.digest}}

Reference the image properties of initContainer vault:

1. Registry URL: {{images.initContainers.vault.registry}}
2. Image name: {{images.initContainers.vault.name}}
3. Image tag:{{images.initContainers.vault.tag}}
4. Digest: {{images.initContainers.vault.digest}}

As mentioned in the example, namespace selector key as managed-state and value as managed will be applied on namespace with label managed-state=managed.

See Documentation for More information.

Please contact Nirmata if you have questions about Kyverno CLI or the 1.3.5. release.

Support for PolicyResultSeverity

Kyverno policy reports provide information about policy execution and violations. Kyverno creates policy reports for each Namespace and a single cluster-level report for cluster resources

In this release, Kyverno supports Severity in PolicyReport Results.

PolicyResultSeverity has one of the following values: – high – low – medium.

The policy severity helps  users to organize the policies depending on the Severity . 

See Documentation for More information.

Kyverno CLI Updates

The Kyverno Command Line Interface (CLI) is designed to validate policies and test the behavior of applying policies to resources before adding the policy to a cluster.

In this release, Kyverno CLI supports a namespace selector and applies pipe through to kubectl for mutate policy.

1. Kyverno apply pipe through to kubectl

New addition flag (-i ) added while running kyverno apply to mutate a resource so output of the command user can  pipe it directly through to kubectl.

Here is the command for apply pipe  through to kubectl  for mutate policy:

kyverno apply /path/to/mutatepolicy.yaml --resource /path/to/resource.yaml --i - | kubectl apply -f -

Here is an example:

Policy.yaml: 

 apiVersion: kyverno.io/v1
 kind: ClusterPolicy
 metadata:
   name: mutate-pods-spec
 spec:
   rules:
     - name: "disable-servicelink-and-token"
       match:
         resources:
           kinds:
             - DaemonSet
             - Deployment
             - Job
             - StatefulSet
           namespaces:
             - test-foo-*
       mutate:
         overlay:
           spec:
             template:
               spec:
                 automountServiceAccountToken: false
                 enableServiceLinks: false 

Resource.yaml:

 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx-deployment
   labels:
     app: nginx
   namespace: test-foo
 spec:
   replicas: 1
   selector:
     matchLabels:
       app: nginx
   template:
     metadata:
       labels:
         app: nginx
     spec:
       containers:
         - name: nginx
           image: nginx:1.14.2
           ports:
             - containerPort: 80 

Once we apply the resource to the mutate policy and pipe through kubectl using command, the output of the file gets applied to the cluster.

See Documentation for More information.

2. Support for namespace selector

Kyverno Cli introduces a new  feature where users can select deployments in namespaces that have a label using Namespace Selector. 

Basically it’s a new filter which filters the resource based on the namespace in which it is created and filters basically on the namespace labels.

Here an example:

 rules:
     - name: validate-name
       match:
         resources:
           kinds:
             - Pod
           namespaceSelector:
             matchExpressions:
             - key: managed-state
               operator: In
               values:
               - managed 

In this example, which will apply to a kind pod.
As mentioned in the example,  namespace selector key as managed-state and value as managed this will be applied on namespace with label managed-state=managed
See Documentation for More information.