Kyverno is a policy engine built for Kubernetes that helps secure and automate Kubernetes configurations. In Kubernetes policies are configurations that govern the configuration and runtime behaviors of other resources. Kubernetes’ declarative configuration management system is powerful, but can be complex to manage. Kyverno addresses this pain point with Kubernetes native policies and reporting.
In the last 24 months, the Kyverno project has grown from 832 to 3733 GitHub stars, a 350% increase, crossed 1.5B downloads, and seen tremendous adoption in the Kubernetes community and ecosystem!
The Kyverno team is proud to announce the pre-release of Kyverno 1.10, one of the largest releases in Kyverno’s history. From significant new features to refactors and enhancements, there’s tons to go through.
Key New Features of Kyverno 1.10
Improved Scalability via Controller Decomposition
Kyverno is the most vast policy engine designed for Kubernetes. Validation, mutation, generation, and even more features make Kyverno an incredibly versatile tool. Up until now, most of those features have been crammed into a single binary run in a single Deployment. This made it difficult to scale and provide granular permissions, and something we heard from users was that they may only want to ever use only a single facet of Kyverno. Now in Kyverno 1.10, we’ve decomposed Kyverno into separate controllers for all of its main pieces of functionality so you can choose which pieces you deploy and scale independently.
Notary Support
Kyverno was a very early adopter of Cosign from Sigstore and it has seen tremendous adoption. But the CNCF Notary project offers a slightly different take on image signatures and artifacts.
Kyverno 1.10 adds initial support for verifying image signatures in Notary v2 format with expanded support planned. Verifying image signatures in Notary format is just as easy and intuitive as it is for Cosign signatures.
apiVersion: kyverno.io/v2beta1
kind: ClusterPolicy
metadata:
name: check-image-notary
spec:
validationFailureAction: Enforce
webhookTimeoutSeconds: 30
failurePolicy: Fail
rules:
- name: verify-signature-notary
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- type: NotaryV2
imageReferences:
- "jimnotarytest.azurecr.io/jim/net-monitor*"
attestors:
- count: 1
entries:
- certificates:
cert: |-
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----Kyverno Extensions via Service Calls
In previous versions of Kyverno, we supported the ability to call the Kubernetes API server which is useful to make decisions about a resource based on information that may not be available in the request directly. This allowed for solving a tremendous number of new use cases, but we continued to hear from users that sometimes additional systems other than Kubernetes itself may need to be consulted and it wasn’t always feasible to replicate that data into Kubernetes API resources. Starting in Kyverno 1.10, you’ll have the ability to call ANY Kubernetes Service (so long as it responds with JSON) and even send POST requests. This will be extremely useful in those situations where you might need to call another application to pass data about the request to understand what action to take.
Mutation and Generation Revamps
Kyverno has enjoyed rich mutation support almost out of the gate. In addition to mutation of requests inbound to the API server, it also has a unique ability not found in other admission controllers to mutate different resources from those in the request. Another hallmark ability is its generation feature, allowing it to create all new Kubernetes resources based upon a policy. Both of these areas received a bunch of significant work making them more robust and also more versatile. For example, mutation for existing resources now supports context variables as well as preconditions allowing you to finely hone in on the existing resources you want to target, and classic generation will now include the resource responsible for the generation in its life cycle. For example, if you so choose, unlabeling a Namespace where the label was part of the matching conditions in which a resource was generated will allow Kyverno to remove that generated resource without any manual intervention.
Closing
With nearly 400 merged pull requests, Kyverno 1.10 is one of the largest releases we have had with nearly every area receiving some attention. Take it for a spin and let us know how it works for you.
Sorry, the comment form is closed at this time.