With diligent efforts from all the contributors and the Kyverno team, we are happy to announce the release of Kyverno v1.5.0!
Although Kyverno v1.4.2 & v1.4.3 had better prospects and improved features, we can say that the version 1.5.0 is twice as good.
Just like every new release, this version comes with new and improved features to better the experience as a Kyverno Adopter. In this article, we will look at some of the new features in Kyverno V1.5.0 and how these features will improve your experience in managing your clusters.
What’s New in V1.5.0?
Foreach for the validate & mutate policies
Several Kubernetes resources contain lists of sub-elements. For example, pods contain lists of containers, init-containers, and volumes. Kyverno policy rules that require looping over these lists and performing conditional checks, or lookups, or updates, were previously to write. That is why we added the new construct called foreach that makes it easier to loop over sub-elements
Here is an example:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-containers
spec:
validationFailureAction: enforce
background: false
rules:
- name: check-names
match:
resources:
kinds:
- Pod
preconditions:
- key: "{{request.type}}"
operator: NotEquals
value: "DELETE"
validate:
message: "Container names must contain the suffix '-valid'"
foreach:
- list: "request.object.spec.containers"
pattern:
name: "*-valid"
We also added a foreach in the mutate policy. This currently works for StrategicMergePatch and the plan is to add support for RFC 6902 JSON patches soon
Here is sample policy of foreach for the mutate policy:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: mutate-images
spec:
rules:
- name: update-registry
match:
resources:
kinds:
- Pod
mutate:
foreach:
- list: "request.object.spec.containers"
patchStrategicMerge:
spec:
containers:
name: "{{ element.name }}"
image: "{{ registry.io/{{images.containers.{{element.name}}.path}}:{{images.containers.{{element.name}}.tag}} }}"
New feature for Cosign attestations
An attestation is signed metadata attached to software artifacts like images. A signed attestation provides verifiable information required for SLSA (Software Levels for Supply Chain Artifacts)
The in-toto attestation format provides a flexible scheme for metadata such as repository and build environment details, vulnerability scan reports, test results, code review reports, or any other information that is used to verify image integrity. In addition to verifying signatures, we added a support to verify signed attestations as part of a policy.
Here is a sample policy for the Cosign attestation:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-image
spec:
validationFailureAction: enforce
background: false
rules:
- name: check-image
match:
resources:
kinds:
- Pod
verifyImages:
- image: "ghcr.io/jimbugwadia/*"
key: |-
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEHMmDjK65krAyDaGaeyWNzgvIu155
JI50B2vezCw8+3CVeE0lJTL5dbL3OP98Za0oAEBJcOxky8Riy/XcmfKZbw==
-----END PUBLIC KEY-----
- image: "ghcr.io/jimbugwadia/*"
key: |-
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEHMmDjK65krAyDaGaeyWNzgvIu155
JI50B2vezCw8+3CVeE0lJTL5dbL3OP98Za0oAEBJcOxky8Riy/XcmfKZbw==
-----END PUBLIC KEY-----
attestations:
- predicateType: https://example.com/CodeReview/v1
conditions:
- all:
- key: "{{ repo.uri }}"
operator: Equals
value: "https://github.com/example/my-project"
- key: "{{ repo.branch }}"
operator: Equals
value: "prod"
CLI test command for mutate policies
In addition to extending the Kyverno test command for the mutate policy, Version 1.5.0 covers all sample policies with the CLI.
Here is the test manifest for the mutate policy. For full test layout, refer to this file.
name: add-labels
policies:
- add_labels.yaml
resources:
- resource.yaml
results:
- policy: add-labels
rule: add-labels
resource: myapp-pod
patchedResource: patchedResource.yaml
kind: Pod
namespace: default
result: pass
- policy: add-labels
rule: add-labels
resource: my-service
patchedResource: patchedResource1.yaml
kind: Service
namespace: default
result: pass
Dynamic webhook configurations
In the previous versions, Kyverno used a wildcard webhook which allowed Kyverno to receive admission requests for all resources.
Kyverno version 1.5.0 provides the dynamic webhook configuration, where the mutatingWebhookConfiguration and the validatingWebhookConfiguration resources are registered and managed dynamically based on the configured policies. This auto generate feature allows Kyverno to only receive admission requests for selected resources hence preventing unnecessary admission requests being forwarded to Kyverno.
The webhook configuration now defaults to “fail-closed”. This provides the guarantee that if a required Kyverno policy cannot be applied, the admission request is rejected. This setting can be managed at a per-policy level, allowing flexibility in choosing how failures for different policy sets should be handled.
More details regarding these latest enhancements can be found in the release notes.
Conclusion
The new features in this release enable a better experience when writing Kyverno policies and allow you to tackle more complex use cases without increasing your learning curve. 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 more about Kyverno, its features and benefits, by visiting this page.
Get certified on Kyverno here.
Sorry, the comment form is closed at this time.