Architecture
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-server
: Thepolicy-server
receives 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.
The policy-server
is the Webhook endpoint called by the Kubernetes API server to validate requests.
The kubewarden-controller
registers the needed
MutatingWebhookConfiguration
or
ValidatingWebhookConfiguration
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)
- the
kubewarden-controller
Deployment - a
PolicyServer
Custom Resource nameddefault
.
When the kubewarden-controller
notices the default PolicyServer
resource,
it creates a Deployment of the policy-server
component.
Kubewarden works as a Kubernetes Admission Webhook.
Kubernetes specifies using TLS to secure all Webhook endpoints.
The kubewarden-controller
sets up this secure communication
by:
- Generating a self-signed Certificate Authority
- Use this CA to generate a TLS certificate key for the
policy-server
Service.
These objects are all stored as Secret
resources in Kubernetes.
Finally, kubewarden-controller
creates the policy-server
Deployment
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.
The kubewarden-controller
notices the new ClusterAdmissionPolicy
resource and
so finds the bound PolicyServer
and reconciles it.