Not even a month after the 1.8.0 release, today we are happy to announce Kubewarden 1.9.0! 🎉🥳

This release includes two major features that have been requested by our community.

Making Rego policies context-aware

Context-aware policies have been introduced with Kubewarden 1.6.0. These policies can obtain information about other Kubernetes resources at evaluation time. This allows them to make decisions based not only on the information provided by the AdmissionReview object they receive.

Initially, this feature was available only to policies written using traditional programming languages. However, starting from the 1.9.0 release, the policies written using Rego can use cluster information.

Kubewarden can run policies written in Rego that target both the Gatekeeper and the kube-mgmt platforms. In both cases, the Kubernetes information is shared with the policy using the same format used by these platforms. That means there’s no need to rewrite your Gatekeeper/kube-mgmt policies. 😎

As proof, look at the unique-ingress policy, which is a copy and paste of this Gatekeeper reference policy.

However, there’s a security improvement provided by Kubewarden: each context-aware policy has access only to the Kubernetes resources specified by the Kubernetes administrator. On the other hand, with Gatekeeper and kube-mgmt, the resources shared with the policies are defined globally. That means that all the policies have access to the same set of Kubernetes resources, regardless of being either context-aware or using all these resources.

Validate generic requests

Initially, Kubewarden was created to validate Kubernetes admission requests. However, our community has recently expressed an interest in reusing the Kubewarden policy platform to write validation/mutation policies not specific to Kubernetes.

Starting from the 1.9.0 release, we introduce the concept of “raw policies”. These are regular Kubewarden policies that validate arbitrary JSON objects. They could validate Terraform plans, GitHub Actions, AWS CloudFormation resources … They are exposed by the Kubewarden Policy Server using the dedicated /validate_raw endpoint.

The Policy Server instances managed by the Kubewarden controller cannot be used to host Raw policies; a user managed one must be allocated to host them. The controller will not allow the user to change the Policy Server ConfigMap to add a Raw policy, since it will try to reconcile it reverting the changes.

More details about raw policies can be found here. A detailed blog post will also be posted in the next few days.

See you around!

As always, we are curious about what features you would like next and how you are enjoying Kubewarden. Reach out on Slack or join our monthly community meeting to talk Kubewarden!

Moreover, if you are attending KubeCon North America Chicago, don’t be shy and visit the Rancher booth to say hello! 🤗