In this article, I will introduce Kyverno’s version 1.6.0 and highlight new features as well as enhancements made in this release for Kubernetes security and more.
The Image Verification Policy
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.
apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: check-image spec: validationFailureAction: enforce background: false webhookTimeoutSeconds: 30 failurePolicy: Fail rules: - name: check-image match: resources: kinds: - Pod verifyImages: - image: "ghcr.io/kyverno/test-verify-image:*" key: |- -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8nXRh950IZbRj8Ra/N9sbqOPZrfM 5/KAQN0/KjHcorm/J5yctVd7iEcnessRQjU917hmKO6JWVGHpDguIyakZA== -----END PUBLIC KEY-----
In 1.6, this rule type was extended with additional features for enhanced Kubernetes security for growing DevSecOps needs!
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 https://www.youtube.com/watch?v=v0nK2xT6D-I&t=2169s.
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 (https://buildpacks.io/ ) used to construct an image https://github.com/buildpacks/spec/blob/main/platform.md#iobuildpackslifecyclemetadata-json.
- 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
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.
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;
- AllIn (replaces In)
- AnyNotIn (replaces NotIn)
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;
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