Kubewarden is a Kubernetes policy engine. It uses policies written in a programming language of your choosing. This language must generate a WebAssembly binary for Kubewarden to use.
The Kubewarden stack consists of these components:
Kubewarden Custom Resources: These are Kubernetes Custom Resources that simplify the process of managing policies.
kubewarden-controller: This is a Kubernetes controller that reconciles Kubewarden's Custom Resources. This controller creates parts of the Kubewarden stack. It also translates Kubewarden configuration into Kubernetes directives.
Kubewarden policies: These are WebAssembly modules holding the validation or mutation logic. WebAssembly modules have detailed documentation in the writing policies sections.
policy-serverreceives requests for validation. It validates the requests by executing Kubewarden policies.
audit-scanner: The audit scanner inspects the resources already in the cluster. It identifies those violating Kubewarden policies.
Kubewarden integrates with Kubernetes using
Dynamic Admission Control.
In particular, Kubewarden operates as a Kubernetes Admission Webhook.
policy-server is the Webhook endpoint called by the Kubernetes API server to validate requests.
kubewarden-controller registers the needed
objects with the Kubernetes API server.
Audit scanner constantly checks the resources declared in the cluster, flagging the ones that no longer adhere with the deployed Kubewarden policies.
The diagram shows the architecture of a cluster running the Kubewarden stack:
The journey of a Kubewarden policy
The architecture diagram appears complex at first. This section covers it step by step.
Default policy server
On a new cluster, the Kubewarden components defined are:
- the Custom Resource Definitions (CRD)
PolicyServerCustom Resource named
kubewarden-controller notices the default
it creates a Deployment of the
Kubewarden works as a Kubernetes Admission Webhook.
Kubernetes specifies using TLS to secure all Webhook endpoints.
kubewarden-controller sets up this secure communication
- Generating a self-signed Certificate Authority
- Use this CA to generate a TLS certificate key for the
These objects are all stored as
Secret resources in Kubernetes.
kubewarden-controller creates the
and a Kubernetes ClusterIP Service
to expose it inside the cluster network.
Defining the first policy
This diagram shows what happens when defining the first policy
bound to the default
policy-server in the cluster:
A policy must define which Policy Server it must run on. Or, we say it binds to a Policy Server. You can have different policies with the same Wasm module and settings running in many Policy Servers. However, you can't have a single policy definition that runs in many policy servers.
kubewarden-controller notices the new
ClusterAdmissionPolicy resource and
so finds the bound
PolicyServer and reconciles it.
When creating, modifying or deleting a
a reconciliation loop activates in
PolicyServer owning the policy.
This reconciliation loop creates a ConfigMap with all the polices bound to the
Then the Deployment rollout of the
It results in starting the new
policy-server instance with the updated configuration.
At start time, the
policy-server reads its configuration from the ConfigMap
and downloads all the Kubewarden policies specified.
You can download Kubewarden policies from remote HTTP servers and container registries.
You use policy settings parameters to tune a policies' behavior.
After startup and policy download the
checks the policy settings provided by the user are valid.
policy-server validates policy settings by invoking
validate_setting function exposed by each policy.
There is further documentation in the
writing policies section
of the documentation.
policy-server exits with an error
if one or more policies received wrong configuration parameters
from the policy specification provided by the user.
If all policies are correctly configured,
spawns a pool of worker threads
to evaluate incoming requests
using the Kubewarden policies
specified by the user.
policy-server starts a HTTPS server,
the Kubewarden Policy Server,
listening to incoming validation requests.
Kubewarden uses the TLS key and certificate
to secure the web server.
The web server exposes each policy by a dedicated path
following the naming convention:
This diagram shows the cluster when initialization of
policy-server is complete:
Making Kubernetes aware of the policy
policy-server Deployment is marked as
kubewarden-controller makes the Kubernetes API server
aware of the new policy by creating either a
MutatingWebhookConfiguration or a
Each policy has a dedicated
which points to the Webhook endpoint served by
The endpoint is reachable by the
/validate/<policy ID> URL.
Policy in action
Now that all the necessary plumbing is complete,
Kubernetes starts sending Admission Review requests to the right
policy-server receives the Admission Request object and,
based on the endpoint that received the request,
uses the correct policy to evaluate it.
Each policy is evaluated inside its own dedicated WebAssembly sandbox.
The communication between
policy-server (the "host")
and the WebAssembly policy (the "guest")
uses the waPC communication protocol.
The protocol description is part of the writing policies documentation.
How Kubewarden handles many policy servers and policies
A cluster can have many policy servers and Kubewarden policies defined. There are benefits of having many policy servers:
You can isolate noisy namespaces or tenants, those generating many policy evaluations, from the rest of the cluster so as not to adversely affect other cluster operations.
You can run mission-critical policies in a dedicated Policy Server pool, making your infrastructure more resilient.
PolicyServer resource defines each
AdmissionPolicy resource defines each policy.
This leads back to the initial diagram:
ClusterAdmissionPolicy is bound to a
ClusterAdmissionPolicies not specifying a
are bound to the
ClusterAdmissionPolicy references a
that doesn't exist, its state is
policy-server defines many validation endpoints,
one for each policy defined in its configuration file.
You can load the same policy many times,
with different configuration parameters.
make the Kubernetes API server aware of these policies.
kubewarden-controller keeps the API server
and configuration resources in synchronization.
The Kubernetes API server dispatches incoming admission requests
to the correct validation endpoint exposed by