Release v0.4.1

v0.4.1

Release v0.4.0

Features

• Introduce a PolicyServer CRD that allow users to describe a Policy Server
  Deployment. The configuration of PolicyServer is now done through this
  resource, instead of using the policy-server ConfigMap.
• ClusterAdmissionPolicy has the following changes:
  • A new PolicyStatus field which can be: unscheduled, unschedulable, pending or active
  • A new condition called PolicyActive.
  • A policyServer attribute. This is used to specify which instance of
    PolicyServer is going to host the policy. If nothing is specified, the
    policy will be scheduled on the PolicyServer named default. This one is
    created by the helm chart at installation time.
• Introduce cert-manager dependency
• PolicyServer and ClusterAdmissionPolicies are now validated and mutated by
  dedicated admission controllers. The kubewarden-controller is acting as
  validation endpoint for both of them.
• All the resources created by the operator are now using
  Finalizers.

Release v0.3.2

Update CHANGELOG.md

Release v0.3.1

This release includes a correct aarch64 controller binary in the published container images on the GitHub registry.

Release v0.3.0

This version has removed support of v1alpha1 ClusterAdmissionPolicy custom resource. You should migrate to v1alpha2 before upgrading to this version.

Release v0.2.3

Update CHANGELOG.md

Release v0.2.2

Update CHANGELOG.md

Release v0.2.1

Do not complain about kubebuilder annotation long lines

Release v0.2.0

The v0.2.0 release of kubewarden-controller introduces a new version of the ClusterAdmissionPolicy custom resource.

Starting from this release, only ClusterAdmissionPolicy of version v1alpha2 are going to be reconciled by the controller.

Upgrade process

This section describes how to migrate a kubewarden deployment from v0.1.4 to
v0.2.0.

Pre-requisites

You must port the v1alpha1 definitions to the v1alpha2 format. We don't offer an automated process for that,
but the operation is pretty straightforward.

The apiGroups, apiVersions, resources and operations are no longer top-level attributes, but rather items under the
new rules attribute.

Consider the following v1alpha1 resource definition:

apiVersion: policies.kubewarden.io/v1alpha1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-capabilities
spec:
  module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.3
  resources:
  - pods
  operations:
  - CREATE
  - UPDATE
  mutating: true
  settings:
    allowed_capabilities:
    - CHOWN
    required_drop_capabilities:
    - NET_ADMIN

The v1alpha2 equivalent would be:

apiVersion: policies.kubewarden.io/v1alpha2
kind: ClusterAdmissionPolicy
metadata:
  name: psp-capabilities
spec:
  module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.3
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations:
      - CREATE
      - UPDATE
  mutating: true
  settings:
    allowed_capabilities:
    - CHOWN
    required_drop_capabilities:
    - NET_ADMIN

Some considerations worth of note:

• With v1alpha1, apiGroups, apiVersions, resources were optional string attributes. Now they are array of
  strings that must have at least one element.
• With v1alpha1, apiGroups, apiVersions, resources were optional string attributes.
  When left empty they would default to the "*" value.

This is reflected in the example above, as you can see the v1alpha2 resource explicitly defines all these attributes.

Upgrade steps

This is a list of steps to perform the upgrade to the v0.2.0 release.

We assume the deployment of Kubewarden has been done using our official helm charts inside of the kubewarden
Namespace.

Delete old controller

As a first step, start by deleting the current kubewarden-controller deployment.
This can be done with the following command:

kubectl delete deployment --namespace kubewarden kubewarden-controller

Note well: Existing policies will continue to work as expected, even while the controller is not running. Removal, creation and update of policies won't be reconciled until the controller is restarted.

Install new Custom Resource Definitions

To install the new CRD definition execute the following commnad:

kubectl apply -f https://raw.githubusercontent.com/kubewarden/helm-charts/kubewarden-controller-0.1.12/charts/kubewarden-controller/crds/clusteradmissionpolicies.yaml

Upgrade your policies

Upgrade all the currently defined ClusterAdmissionPolicy resources to use the v1alpha2 version.

This can be done via:

kubectl apply -f <upgrade-policy.yaml>

Upgrade the helm release

It's time to upgrade the helm release, this can be done via:

helm upgrade kubewarden-controller --version 0.1.12 kubewarden/kubewarden-controller

Once this is done, the new version of the kubewarden-controller will be running on our cluster. The policy-server instance will keep operating as expected during the whole time. It won't even be restarted, unless you
changed some details about the ClusterAdmissionPolicy resource apart from the version itself.

Release v0.1.4

Update CHANGELOG.md