We are thrilled to announce the release of Kubewarden v1.17.0. This release is packed with big features, let’s have a look!

Certificate rotation & removal of cert-manager dependency

Starting from this release, the Kubewarden stack takes care of creating and rotating all the needed TLS certificates and certificate authorities.

Kubewarden, by virtue of connecting to the Kubernetes API server, needs TLS certificates for both the kubewarden-controller (when creating webhooks for its policies) and for the PolicyServers (so they can report their results to the Webhook API server).

Up until v1.16, the certificate authority (CA) and leaf certificates used by kubewarden-controller to connect to the Webhooks API were generated by cert-manager. The certificates used to register our PolicyServers with the Kubernetes Webhook API were, and continue to be, generated by our controller. Our controller generates a self-signed Certificate Authority that is used to sign all the PolicyServer certificates. These had a 10 year expiration date. Certificate rotation for all these was left to the user.

From v1.17 onwards, we generate the CA and certificate on Helm install or upgrade if not present, under kubewarden-ca Secret. This means we don’t depend on cert-manager anymore. The CA defaults to a 10 year expiration date, and the leaf certificates to a 1 year expiration date.

In addition, now the kubewarden-controller rotates both the CA and the needed certificates for the webhooks and PolicyServers on its own, 1 month before the expiration date. Care is taken to ensure a valid overlap of old and new certificates, and removal of old certificates as soon as possible for security reasons.

So, cert-manager can now be removed if it was installed as a dependency of Kubewarden. It can be left installed if it is being used for other workloads.

The v1.17 Helm chart also contains post-install and post-upgrade hooks to perform the needed cleanups of leftover Secrets (webhook-secret-cert, now kubewarden-webhook-secret-cert) when upgrading to v1.17.

New policy types: Policy Groups

Starting from V1.17, the Kubewarden stack now supports 2 new Kubernetes Custom Resources:

• AdmissionPolicyGroups: Namespaced policy comprised of several policies.
• ClusterAdmissionPolicyGroups: Clusterwide policy comprised of several policies.

These new Policy Groups resources define a policy comprised of several policies and their policy settings, and they perform a combined evaluation of those multiple policies using logical operators.

This reuses existing policies, reducing the need for custom policy creation, and providing complex logic while at the same time reducing complexity (thanks to using existing policies, or for example using CEL via the cel-policy).

However, while ordinary policies can include mutation logic to modify resources during admission, policy groups are limited to validation only.

Configuration for policy groups is similar to that of ordinary policies. The difference is the addition of the expression, message, and policies fields, as well as the declaration of context-aware rules in a different location.

Here is an example of a ClusterAdmissionPolicyGroup that makes sure a Service selector is unique or owned by a specific team:

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicyGroup # or AdmissionPolicyGroup
metadata:
  name: unique-service-selector
spec:
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["services"]
      operations: ["CREATE", "UPDATE"]
  policies:
    unique_service_selector:
      module: registry://ghcr.io/kubewarden/policies/unique-service-selector-policy:v0.1.0
      contextAwareResources:
        - apiVersion: v1
          kind: Service
      settings:
        app.kubernetes.io/name: MyApp
    owned_by_foo_team:
      module: registry://ghcr.io/kubewarden/policies/safe-annotations:v0.2.9
      settings:
        mandatory_annotations:
          - owner
        constrained_annotations:
          owner: "foo-team"
  expression: "unique_service_selector() || (!unique_service_selector() && owned_by_foo_team())"
  message: "the service selector is not unique or the service is not owned by the foo team"

As usual, the CRDs are documented in our reference docs. And you can read their explanation and an in-depth how-to on the docs for these resources.

Stay tuned for a new deep dive blog post!

Policy updates

During this development cycle, we have updated the following policies maintained by us.

cel-policy

The cel-policy, is our policy that bundles and extends Kubernetes' cel-go library, got some nice additions:

• Enabled lazy evaluation for variables.
• Bumped cel-go library to v0.21.0: This allows us to consume nifty things like math extensions for bitwise ops and floats, better support for custom types and type registries, improved nested rules and variables, between others.
• We automated all bumps of cel-go, k8s.io/apiserver, and other libraries, thanks to updatecli.

verify-image-signatures

The verify-image-signatures policy now allows mutation of all the workload resources associated with it.

trusted-repos-policy

Quite the list of changes for this policy with a big refactor for maintenance. This includes:

• Added support for all workload resource types other than Pod.
• Move to the oci-spec crate to parse OCI references and drop our custom parsing. This also adds settings validation for images, registries, and tags that are not compliant with the OCI spec.
• Detect the implicit latest tag.
• Increase test coverage to almost 100%, and introduce end-to-end tests.

Getting in touch

As always, you can contact us through Slack and GitHub discussions.