How to Use Kubewarden to Validate Incoming Requests Using Policies Written in WebAssembly

In this blog post, we will be discussing how to use Kubewarden to validate incoming requests using policies written in WebAssembly. We will also be discussing the benefits of using Kubewarden and the steps involved in using it.

Getting started on a kubernetes cluster

Requirements:

• Kubernetes cluster (I’m running v1.26)
• Currently the chart depends on cert manager you will have to run the commands provided before installing kubewarden
• Helm installed (package manager)

Okay so for installing the cert manager you will run the following commands on your cluster

kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml

You should see some output of the cert-manager installed on namespace and some other items after this next command

kubectl wait --for=condition=Available deployment --timeout=2m -n cert-manager --all

Next we will install the helm charts and should get up and running

helm repo add kubewarden https://charts.kubewarden.io

helm install --wait -n kubewarden --create-namespace kubewarden-crds kubewarden/kubewarden-crds

helm install --wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller

helm install --wait -n kubewarden kubewarden-defaults kubewarden/kubewarden-defaults

So as of now we should have the kubewarden-crds which register the ClusterAdmissionPolicy and PolicyServer CRD. Along with the kubewarden-controller, kubewarden-defaults.

Ubiquitously this installs the default policy server on your cluster. This server will enforce some well-known best practices for securing your cluster.

To understand the syntax of the PolicyServer we will analyze this YAML input provided by the docs.

apiVersion: policies.kubewarden.io/v1   #calling the REST API
kind: PolicyServer                      
metadata:
  name: reserved-instance-for-tenant-a
spec:
  image: ghcr.io/kubewarden/policy-server:v1.3.0
  replicas: 2
  serviceAccountName: ~
  env:
  - name: KUBEWARDEN_LOG_LEVEL
    value: debug

If you’ve been following my previous post this looks awfully familiar to how we enable audit logging with the same syntax which makes this portable and easy to get started.

Kubewarden has a policy hub which has recently moved to artifacthub.io

https://artifacthub.io/packages/search?kind=13&sort=relevance&page=1

We will need kwctl cli tool for these policies so I won’t go through the installation piece.

Reference: https://github.com/kubewarden/kwctl

So let’s get started with a demo on the policy for the quick start this is annotated as the following YAML

kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: privileged-pods
spec:
  module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.2.2
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations:
    - CREATE
    - UPDATE
  mutating: false
EOF

Run the command below to verify our policy is running in the default server

kubectl get clusteradmissionpolicy.policies.kubewarden.io/privileged-pods

Then run the next command to check on our validating webhook configurations

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l kubewarden

Let’s run the following of a un-privileged pod in our cluster

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: unprivileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
EOF

And our pod is created judging by our output

Now let’s test a privileged pod with the flag under a securityContext

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
      securityContext:
          privileged: true
EOF

As we can see the policy restricts this usage which means it calls the admission webhook and was rejected.

As noted by the documentation since we didn’t necessarily define a namespace the policy is still applied due to the scope of being cluster-wide and not necessarily targeting a specific namespace.

This is just a short use-case by documentation and following along but this does feel relatively easy to enforce a policy on our cluster the use case can be narrow or wide as we can see in what we’d like to not happen in our cluster.

From a CNCF perspective Kubewarden is still in the Sandbox status use this as needed but also realize this is still in its earliest stages the extensive use is unlocked with the CLI tool as this pulls from artifacthub.io some out of the box policies for you.

What is Kubewarden?

Kubewarden is a policy enforcement tool that uses WebAssembly (Wasm) to validate incoming requests. It provides a number of benefits, including:

• Improved security by allowing you to enforce policies that can’t be bypassed by malicious users;

• Reduced complexity, as all validation logic is contained within the Wasm module;

• Better performance, as Wasm modules can be executed natively by the CPU.

Conclusion

In conclusion, Kubewarden is a powerful tool that can be used to validate incoming requests using policies written in WebAssembly. The benefits of using Kubewarden include the ability to enforce fine-grained control over what requests are allowed and the flexibility to write policies in any language that can compile to WebAssembly. If you’re looking for a way to secure your Kubernetes cluster, Kubewarden is definitely worth considering.