kubewarden / helm-charts

Helm charts for the Kubewarden project

Kubewarden helm-charts

This repository contains the helm charts used to deploy the Kubewarden stack.

helm-charts's Issues

Update the custom resources the helm-chart creates

The helm chart is currently creating the ClusterAdmissionPolicy custom resource definition. It should now create:

• The new version of the ClusterAdmissionPolicy described in kubewarden/kubewarden-controller#49: v1alpha3.
• The new CRD PolicyServer.

Remove PolicyServer resources in a pre-delete helm hook

Currently users have to manually delete clusteradmissionpolices before deleting the helm chart or resources will not be removed https://docs.kubewarden.io/quick-start.html#uninstall
Add a helm pre-delete hook that deletes all PolicyServer resources. Then the controller will remove all policy server deployments, services, configmaps, secrets and all the clusteradmissionpolicies bounded to this PolicyServer.

Check NeuVector documentation what are the PSPs installed when the user enable the "best practices PSPs" feature in their product.

We adding a new Helm chart to install a default Policy Server, see more in #52 . We could take this opportunity to install some default policies in the cluster as well. Thus, let's look in the NeuVector documentation which PSPs they install in the customer cluster when the users enable the "best practices PSPs" feature. Once we have this information, let's decide if we should add this policies in the chart or not.

feat: Add Artifact Hub metadata to chart

Helm charts can have annotations and there are some specific ones for Artifact Hub. Some of these could be useful to customize the display.

For example, artifacthub.io/links can hold a list of links. A link to the docs site could be added.

Update rancher-version annotation to include 2.7 versions in kubewarden-controller

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When attempting to install the latest kubewarden-controller chart from the UI with a Rancher version v2.7.0, the latest versions of the chart do not appear. This is causing the installation to fail as the kubewarden-crds chart is not being auto-installed along with the controller.

I believe this annotation needs to be updated to include 2.7.0 versions of Rancher, or rewritten to >= 2.7.0-0 <= 2.7.100-0 as v2.7.0 is the first with the extensions support.

Expected Behavior

All of the latest versions should appear and should include the crd auto-install.

Steps To Reproduce

1. With Rancher v2.7.0 attempt to install Kubewarden from the UI guided steps

Anything else?

Response from chart fetch

Add the `capabilities-psp-policy` in the recommended policies list from `kubewaraden-default` chart

In order to increase the security of the cluster running the recommended policies, we should add the capabilities-psp-policy in the policies installed in the cluster. This will help the mitigation of the threat #8 of the threat model.

The policy should block the NEW_RAW capability in the pods launched in the namespaces besides ones defined in the skip list

NOTE: This is an issue created from RFC discussing the admission control threat model. It's created to allow the Kubewarden team discuss the proposed mitigation further and start to work on each actionable item when possible

feat: Schema files

Helm charts can include schema files. The schemas are useful as Helm will validate them and they can be used for other purposes, such as generating forms (here's a react example).

There's a Helm plugin that can stub out a schema. Once you have the stub there is still information to be filled it. It provides the structure. It can't fill in things like a description.

Extract registry to a separate field in the helm charts values.yaml

Extract registry to a separate field in the helm charts values.yaml

Duplicated policy and image files in a release

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

After recent changes in the release CI to add files with list of policies and images a release ended having two versions of the same file.

Expected Behavior

The release should have one file for the policy list and another one for the image list

Steps To Reproduce

No response

Environment

- OS:
- Architecture:

Anything else?

No response

"No such file or directory" error occurred when creating ClusterAdmissionPolicy

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Install the latest kubewarden and create a policy file as follows：
apiVersion: policies.kubewarden.io/v1alpha2 kind: ClusterAdmissionPolicy metadata: name: privileged-pods spec: policyServer: default module: file:///test/policy.wasm rules: - apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] operations: - CREATE - UPDATE mutating: false
The wasm policy file has been downloaded and placed on the host.

Expected Behavior

Policy successfully created

Steps To Reproduce

No response

Environment

- OS:Linux
- Architecture:x86

Anything else?

Is there something wrong with the way I use it? Who can tell me？

Missing securityContext in Helm Charts

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

The securityContext in controller deployment is hard-coded and cannot be configured like "fsGroup" or "MustRunAs".
The pre-deletion job has no securityContext and can not be configured. Also the policy server deployment has no securityContext and I have no idea how to configure.

Expected Behavior

Full feature set securityContext in Helm Chart.

Steps To Reproduce

Install Charts with default settings. Try to set securityContext without any affect

Environment

- OS: Linux
- Architecture: amd64

Anything else?

thx

Release helm chart with new policy-server and new kubewarden-controller

Release a new helm chart with the new policy-server and kuberwarden-controller:

• Policy server: 0.1.10
• kubewarden-controller: 0.3.2

Acceptance criteria

• Smoke testing that consists in deploying the helm chart with the new images and deploy a policy that accepts and reject some resources.

Write release notes for the chart deploying the new architecture

We should write release notes for the helm chart version that introduces the new architecture.

The goals are:

• Explain what changed
• Provide manual instructions, if needed, for people upgrading from an older release

Feature Request: Use the same values.yml for the 3 charts

Is your feature request related to a problem?

From #70 (comment), a future problem arises: values from the different charts may be tightly coupled. Example:

• kubewarden-controller chart has policyServer.default.name, which sets the default PolicyServer name that the controller will give to policies when the policies don't specify their spec.policyServer.
• kubewarden-defaults chart has policyServer.name, which sets the name of the CR that will be created.
• Both should match.

Solution you'd like

Craft the values.yml of the 3 charts in a way that they can all be merged into 1 values.yml. Effectively having just 1 values.yml for the 3 charts. The charts are tightly coupled, I believe it's fine if the values.yml are tightly coupled as well.

A. This could mean namespacing each of the values of each chart under a key with their chart name:

kubewarden-controller:
  policyServer.default.name: foo
  ...
kubewarden-defaults:
  policyServer.name: foo
  ...

B. Or we could merge all the keys from all the charts to form 1 kubewarden-values.yml, linting so there aren't any conflicts. We could also use templating to reduce repetiton (e.g: foo in example of (a)), or better, merge those 2 keys into 1 that both charts would use.

Alternatives you've considered

No response

Anything else?

No response

Trigger E2E tests after chart changes

Updates the CI/CD pipeline to run the E2E tests when the charts are changed. The E2E tests should validate if the chart does not have issues

Sign Helm charts

To ensure that the Kubewarden users are using the right software versions and binaries from the Kubewarden team, we should sign the Helm charts using Sigtore infrastructure.

See more at threat kubewarden threat #1

NOTE: This is an issue created from RFC discussing the admission control threat model. It's created to allow the Kubewarden team discuss the proposed mitigation further and start to work on each actionable item when possible

helm charts: evaluate creation of SBOM files

Each release should have a SBOM file that allows to track the origin of all the dependencies.

It looks like this project can do it: https://github.com/defenseunicorns/sbom-cli

Acceptance criteria:

• Figure out if it make sense (from a technical POV) to have SBOM files for helm charts (are they a real thing?)
• Implement creation of SBOM files

Allow to inject custom certificate authorities

It should be possible for the user to provide a list of their own custom certificate authorities that can be used along with the system ones. This can be useful when some or all policies are in an OCI registry or HTTPS server served with a chain of trust that requires custom PKI.

Depends on kubewarden/kubewarden-controller#41

Add kubewarden-images.txt to releases

Add kubewarden-images.txt to releases. Add a text file with the images with the right version in the release. See rancher releases

feat: Add questions.yaml to `kubewarden-defaults`

When deploying KW UI, and deploying kubewarden-defaults, I didn't find a button to enable the default policies, and did it by changing the yaml instead.

This is not easily discoverable for new users.

Relates to rancher/kubewarden-ui#68

Acceptance criteria

kubewarden-controller & kubewarden-defaults have the most used values exposed through questions.yaml.

Allow users to upgrade Policy Server using Helm chart

After installing the Kubewarden stack it is not possible to change configuration values with the helm upgrade command

Reproducible steps

1. Launch Kubernetes cluster

$ cat k3d-default.yaml
---
apiVersion: k3d.io/v1alpha3
kind: Simple
name: k3s-default
servers: 1
agents: 0
image: docker.io/rancher/k3s:v1.22.4-k3s1

$ k3d cluster create $(PROFILE) --config k3d-default.yaml -v /dev/mapper:/dev/mapper
$ kubectl wait --for=condition=Ready nodes --all

2. Install Kubewarden stack

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.5.3/cert-manager.yaml                                                                                                                                  
$ kubectl wait --for=condition=Available deployment --timeout=3m -n cert-manager --

$ cat kubewarden-controller-values.yaml 
telemetry:
  enabled: false
policyServer:
  image:
    repository: ghcr.io/kubewarden/policy-server
    tag: "v0.2.5"
  replicaCount: 1
  telemetry:
    metrics:
      port: 8080
  env:
    - name: KUBEWARDEN_LOG_LEVEL
      value: debug
  annotations: {}

$ helm repo add --force-update kubewarden https://charts.kubewarden.io                                                                                                                                                                  
$ helm upgrade --install --wait --namespace kubewarden --create-namespace kubewarden-crds kubewarden/kubewarden-crds                                                                                                                    
$ helm upgrade --install --wait --namespace kubewarden --values kubewarden-controller-values.yaml kubewarden-controller  kubewarden/kubewarden-controller 

3. Upgrade Kubewarden release changing some configuration

$ cat values.yaml                      
policyServer:
  replicaCount: 2
  image:
    tag: "v0.2.4"

$ helm upgrade  --namespace kubewarden --values values.yaml kubewarden-controller kubewarden/kubewarden-controller

4. Check if the policy server definition is updated

$ kubectl get policyservers default -o=jsonpath="{['.spec.image', '.spec.replicas']}"
ghcr.io/kubewarden/policy-server:v0.2.5 1%

CI/CD pipeline changes for major and minor releases

Update the CI/CD pipelines to allow the major/minor updates of all charts. This means that when a component (kubewarden-controller, kubewarden-crds or policy-server) has a major/minor version release, the CI/CD pipeline in the helm-chart repository should release all Helm charts to keep all the components in sync

Publish charts to artifacthub.io

The Kubewarden helm charts should be discoverable via artifacthub.io

Make the resource allocation configurable via the chart values file

Hi
Could you please make the resource allocation configurable here: https://github.com/kubewarden/helm-charts/blob/main/charts/kubewarden-controller/templates/deployment.yaml#L58
It's a fairly common configuration point.

Many Thanks

Ensure the policy-server has enough rights to list contextual resources

The policy-server today is fetching a list of well known (and static) resources, being:

• Namespaces
• Services
• Ingresses

Until we make this configurable and extendable with custom resources, the policy-server needs to have enough rights in the Kubernetes cluster to list this resources, so context-aware policies can use this information to take contextual decisions (or perform contextual-aware mutations).

Acceptance criteria

• The policy-server deployed through the controller started by the helm chart is able to list namespaces, services and ingresses in all namespaces.

Verified and Official on Artifact Hub

The artifact hub has the ability to have verified and official repos and charts. The docs are at https://artifacthub.io/docs/topics/repositories/#verified-publisher

Deploy the `default` `PolicyServer` by default

When using the helm chart, a default PolicyServer will be created, forwarding the attributes exposed on the values.yaml that we currently have:

• replicaCount
• image
• serviceAccountName: policy-server

The policy-server service account is created with the same rights as today, and is defaulted in the helm chart if not provided. Nothing has to change in this regard.

Trigger CI/CD pipeline from another repositories

Update the CI/CD pipeline to allow other repositories trigger chart releases.

helm chart is missing Rancher-specific README

When adding https://chimera-kube.github.io/helm-charts to the "Apps & Marketplace" charts in Rancher, there's no detailed information shown for the helm chart.

Instead

This chart doesn't have a Rancher-specific README. Review the Helm README to learn more about the available configuration options and their usage.

is displayed

Acceptance criteria

• research what a "Rancher-specific README" is
• add such a readme
• verify in a Rancher installation

Default memory with 50Mi too low

Just did a standard deployment with 50Mi using kubewarden-controller 1.2.4 helm chart (v1.3.0) and got OOM in the kubewarden-controller.

Deployment has been done on RKE2 1.24.4 in a 3 node Rancher cluster.

Seems we need to change / increase the default here:

helm-charts/charts/kubewarden-controller/values.yaml

Line 76 in e2fbce9

memory: 50Mi

From Grafana:

I assume we should start with 200Mi...

Take care of supporting CertManager

With the new architecture the controller provides a mutation and validation Webhook endpoint. The Webhook must be secured via a certificate in order to be used by Kubernetes.

As a result of that, CertManager is going to become a dependency of Kubewarden. This is going to be used to create and renew this certificate.

The helm chart should take care of installing CertManager.

Acceptance criteria

• [ ] The values.yaml file has a new boolean flag that enable/disable the installation of CertManager
• By default installing Kubewarden via our helm chart leads to the deployment of CertManager too
• If desired, the user can set this flag to false. This will prevent our helm chart from deployment CertManager
• values.yaml has new flags for enabling cert-manager annotations, and creating a self signed cert with cert-manager. If desired, the user can set these flags to false, to opt out of 1 or both. Automatic creation of a self signed certificate without cert-manager will be discussed in a different card (either to be done by a job, or implemented as a controller option).
• The documentation of our helm chart is updated to reflect this dependency and the usage of this new flag
• The quickstart documentation is updated to reflect this dependency and the usage of this new flag: kubewarden/docs#51
• Update https://charts.kubewarden.io/#configuration GH page

Run container images with readonly filesystem

Running container images with a read-only filesystem is considered a good security practice. I think we can achieve that both for policy-server and for kubewarden-controller.

For policy-server we will need to declare an emptyDir volume to store the policies that are being downloaded.

Acceptance criteria

• policy-server deployment has a read-only container image
• kubewarden-controller has a read-only container image

Feature Request: Expose verification config in helm chart

Is your feature request related to a problem?

Configuring a PolicyServer to enable verification is already done, see https://github.com/kubewarden/kubewarden-controller/blob/6013ca6919c3711d4e1ebbc8afec0c2e5b38dc59/config/crd/bases/policies.kubewarden.io_policyservers.yaml#L181.

The ConfigMap gets already mounted by the controller. But, chart users need to expose that.

Solution you'd like

Come up with a good UX for helm chart users for enabling verification. We can't enable verification by default as we don't know the source of their policies/images.

Examples:

• Accept a configmap name as chart value. The user creates the configmap (in kubewarden) on their own. Check RBAC.

Alternatives you've considered

Accept configmap content as chart value (this poses problems with ugprade. Who owns the ConfigMap?)

Anything else?

No response

Handle Secret containing a docker config file

This is related with kubewarden/kubewarden-controller#42

We need to offer the following scenarios via our helm chart:

1. User has already a Kubernetes Secret that contains the docker configuration file that allows pull operations. The user just enters the name of the Secret into values.yml -> The helm chart writes the name of the Secret inside of the policy-server ConfigMap
2. The user provides the contents of the docker configuration file via the values.yml file -> the helm chart creates a Secret and then adds a reference to it inside of the policy-server ConfigMap
3. When none of the previous scenarios happen, no Secret is referenced inside of the ConfigMap. This is the current behavior

Remove duplicated helm charts

Because of a small mistake in our automation pipeline (see #174) some of our helm charts had duplicates inside of their name.

Next time a new helm chart is going to be released, the fix from the previous PR will create new helm charts with proper name. Once that's done, we have to manually remove the charts with the ugly names.

Patch version chart releases workflow

Update the CI/CD pipelines to allow the patch update of the individual chart releases. This means that when a component (kubewarden-controller, kubewarden-crds or policy-server) has a patch version release, the CI/CD pipeline in the helm-chart repository should release only the related Helm charts.

Improve the Rancher manifest

The Rancher manifest allows charts to ask questions to the users, which is a really convenient way to provide chart values.

Right now our manifest doesn't ask any question.

Acceptance criteria

Ensure our Rancher manifest asks the following questions

• imagePullSecrets
• image.repository
• image.tag
• policyServer.replicaCount
• policyServer.image.repository
• policyServer.image.tag

Set recommended labels in all charts, accept `.Values.additionalLabels`

#176 adds some recommended labels to resources created from kubewarden-controller chart, and allows the user to set their own, useful for node selection, load, etc.

It would be nice to expand on this.

Acceptance criteria

Add the missing labels from the recommended labels list to kubewarden-controller, kubewarden-defaults, kubewarden-crds chart.

app.kubernetes.io/part-of: kubewarden
app.kubernetes.io/name: kubewarden-controller
app.kubernetes.io/instance: kubewarden-controller-abcxzy
                           (with correct string generation, maybe matching the helm one?)

Add a new .Values.additionalLabels, that gets honored, to those charts too.

release v1.0.1

create a v1.0.1 release with the verification fix from sigstore-rs

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

---

Warning

Renovate failed to look up the following dependencies: Failed to look up docker package kubewarden/kubewarden-controller, Failed to look up docker package kubewarden/kubectl, Failed to look up docker package kubewarden/audit-scanner, Failed to look up docker package kubewarden/policy-server.

Files affected: charts/kubewarden-controller/values.yaml, charts/kubewarden-defaults/values.yaml

---

This repository currently has no open or pending branches.

Detected dependencies

github-actions

.github/workflows/ci.yaml

• actions/checkout v4.1.6@a5ac7e51b41094c92402da3b24376905380afc29

.github/workflows/e2e-tests.yml

• actions/checkout v4.1.6@a5ac7e51b41094c92402da3b24376905380afc29
• kubewarden/kubewarden-end-to-end-tests main

.github/workflows/helm-chart-release.yml

• actions/checkout v4.1.6@a5ac7e51b41094c92402da3b24376905380afc29
• azure/setup-helm v3.5@5119fcb9089d432beecbf79bb2c7915207344b78
• sigstore/cosign-installer v3.5.0@59acb6260d9c0ba8f4a2f9d9b48431a222b68e20
• helm/chart-releaser-action v1.6.0@a917fd15b20e8b64b94d9158ad54cd6345335584
• peaceiris/actions-gh-pages v4.0.0@4f9cc6602d3f66b9c108549d475ec49e8ef4d45e
• docker/login-action v3.1.0@e92390c5fb421da1463c202d546fed0ec5c39f20

.github/workflows/update-charts.yml

• actions/github-script v7.0.1@60a0d83039c74a4aee543508d2ffcb1c3799cdea
• actions/checkout v4.1.6@a5ac7e51b41094c92402da3b24376905380afc29
• actions/github-script v7.0.1@60a0d83039c74a4aee543508d2ffcb1c3799cdea
• actions/github-script v7.0.1@60a0d83039c74a4aee543508d2ffcb1c3799cdea
• updatecli/updatecli-action v2.58.0@fa41baa922561b436c449de1a0bd1f5bd768248c
• actions/checkout v4.1.6@a5ac7e51b41094c92402da3b24376905380afc29
• actions/github-script v7.0.1@60a0d83039c74a4aee543508d2ffcb1c3799cdea
• actions/github-script v7.0.1@60a0d83039c74a4aee543508d2ffcb1c3799cdea
• actions/github-script v7.0.1@60a0d83039c74a4aee543508d2ffcb1c3799cdea
• updatecli/updatecli-action v2.58.0@fa41baa922561b436c449de1a0bd1f5bd768248c

.github/workflows/update-dependencies.yaml

• actions/checkout v4.1.6@a5ac7e51b41094c92402da3b24376905380afc29
• updatecli/updatecli-action v2.58.0@fa41baa922561b436c449de1a0bd1f5bd768248c

helm-values

charts/kubewarden-controller/values.yaml

• kubewarden/kubewarden-controller v1.13.0-rc1
• kubewarden/kubectl v1.27.14
• kubewarden/audit-scanner v1.13.0-rc1
• ghcr.io/kyverno/policy-reporter 2.19.0
• ghcr.io/kyverno/policy-reporter-ui 1.9.2

charts/kubewarden-defaults/values.yaml

• kubewarden/policy-server v1.13.0-rc1

helmv3

charts/kubewarden-controller/Chart.yaml

• policy-reporter 2.23.1

---

• Check this box to trigger a request for Renovate to run again on this repository

feat: PGP Signed Helm Chart

Helm has a feature to sign and verify charts so that the provenance and integrity can be checked. Given that kubewarden is around security, this could be useful to use.

There is a plugin to make this easier with GPG.

On Artifact Hub there is a badge to show the provenance file. Here's an example. The badge shows up in search, too.

Update to support controller's Webhooks

The new architecture relies on some controller Webhook to mutate/validate Kubewarden's resources. We have to ensure the helm chart creates the right RBAC permissions to allow the controller to work.

`kubewarden-defaults` chart: expose all the parameters supported by PolicyServer CRD

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

The kubewarden-defaults helm charts takes care of deploying the default instance of Policy Server. The helm chart however, doesn't expose all the parameters supported by the PolicyServer CRD.

This is a problem when, for example, the Policy Server image being used is being pulled from a private registry that has authentication. In this case, the definition of the Policy Server Deployment needs to have a imagePullSecret configured.

Expected Behavior

The helm chart exposes the values of the PolicyServer CRD via its values.yaml file:

• imagePullSecret
• insecureSources
• sourceAuthorities

Steps To Reproduce

No response

Environment

No response

Anything else?

No response

Add missing README file

On Artifact Hub, neither the kubewarden-controller nor the kubewarden-crds charts have a README.

Acceptance criteria

• Add README to kubewarden-controller helm chart
• Add README to kubewarden-crd helm chart

Separate CRDs into its own chart

CRDs defined in the /crd folder cannot be upgraded, may overlap with already defined CRDs in the cluster from a different user and silently substitute them, cannot be safely removed when several charts depend on them, and other dangerous and destroying behaviours. In addition, they can't be templated either.

We should consider using a separate chart for CRDs in the future.

More info:
https://helm.sh/docs/chart_best_practices/custom_resource_definitions/
https://github.com/helm/community/blob/f9e06c16d89ccea1bea77c01a6a96ae3b309f823/architecture/crds.md

Can not specify / use a ClusterIssuer for kubewarden tls cert

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When deploying cert-manager we create a CA and a ClusterIssuer and want to use the ClusterIssuer also for Kubewarden.
Unfortunately the helm chart does not allow to specify the usage of a ClusterIssuer. Seems there is just support for an "Issuer".

Expected Behavior

ClusterIssuer should be able to be used.

Steps To Reproduce

1. deploy cert-manager with self-signed CA and create a ClusterIssuer
2. try to use the ClusterIssuer with Kubewarden helm chart deployment

Environment

- OS: Linux / SLES 15 SP4
- Architecture: x86_64

Anything else?

No response

Split skipNamespaces

Is your feature request related to a problem?

Always defining all rancher namespaces in my fleet configuration seems unnecessarily and redundant.

Solution you'd like

Create two arrays instead:

  rancherNamespaces: []
  skipNamespaces: []

and use them in the helper:

{{- with .Values.recommendedPolicies.rancherNamespaces }}
      {{- toYaml . | nindent 6 }}
{{- end }}
{{- with .Values.recommendedPolicies.skipNamespaces }}
      {{- toYaml . | nindent 6 }}
{{- end }}

Alternatives you've considered

No response

Anything else?

No response

Add the `hostpaths-psp-policy` in the recommended policies list from `kubewaraden-default` chart.

In order to increase the security of the cluster running the recommended policies, we should add the hostpaths-psp-policy in the policies installed in the cluster. This will help the mitigation of the threat #16 of the threat model. The policy should allow hostPath volume in some directories. These directories can be define in the values of the chart.

NOTE: This is an issue created from RFC discussing the admission control threat model. It's created to allow the Kubewarden team discuss the proposed mitigation further and start to work on each actionable item when possible

Upgrade kubewarden-controller to v0.2.0

Update the chart to deploy kubewarden-controller v0.2.0.

Note well, this kubewarden-controller release introduces quite some significant changes:

• Upgraded from kubebuilder v2 -> v3
• Added new CRD

These changes caused quite some of the deployment yaml file to change.

Add webhooks patch permission to controller role

Controller should have permission to patch and watch webhooks