Admission policy with Kubewarden

This page is for a platform team that runs Kubewarden and wants admission policy for Lolly Work's pods. Lolly Work publishes what its pods need as data and a ready policy set built from published Kubewarden policies. Nothing is installed with the Helm chart: a cluster without Kubewarden runs Work unchanged, and the set applies only to namespaces you label. For running Kubewarden itself, and for rehearsing in audit mode first, see WebAssembly and Kubewarden choices.

Three files in the lolly-work repository make up the set:

What Work's pods need

Work has up to five kinds of container: the control plane, the migration Job, the optional render worker, and the optional copy steps that fill the pack and web app volumes from your images. With the chart's defaults, each of them:

Some chart values change that list:

Images and their signatures. The two images are ghcr.io/lolly-tools/lolly-work-server and ghcr.io/lolly-tools/lolly-work-render-worker. Both are signed keyless with Sigstore by lolly-work's release workflow at a release tag:

The signatures are Sigstore bundles stored as OCI referrers, as cosign 3 writes them; there is no .sig tag. To check one by hand:

cosign verify ghcr.io/lolly-tools/lolly-work-server@sha256:<digest> \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github\.com/lolly-tools/lolly-work/\.github/workflows/release\.yml@refs/tags/v'

Network. The control plane accepts traffic on port 8787 and, by default, may reach anything: PostgreSQL, your identity provider, catalog sources, mail relays and the SIEM receiver. The render worker accepts connections from the control plane only, on port 8791. Its NetworkPolicy lets it reach cluster DNS and public addresses on ports 80 and 443, and its own code refuses the same private, shared, loopback, link-local (which includes cloud metadata at 169.254.169.254), documentation and multicast ranges, so a rendered page cannot reach the cluster or the metadata service. The requirements file lists every range.

The policy set

Every module is pinned by tag and digest in policies.yaml. Two policies mutate pods: lolly-work-user-group fills an unset container UID or GID with 1000, and lolly-work-image-signatures replaces an image tag with the digest it verified. The others only admit or refuse.

Apply the set

Label the namespace Work runs in, apply the policies and wait for them:

kubectl label namespace lolly-work lolly.tools/policy-set=lolly-work
kubectl apply -f deploy/kubewarden/policies.yaml
kubectl wait --for=condition=PolicyActive clusteradmissionpolicy \
  -l app.kubernetes.io/part-of=lolly-work-policy-set --timeout=5m

The policies apply to every Pod in a labelled namespace, so keep PostgreSQL and other workloads in a namespace of their own, and let only cluster administrators change namespace labels. The Policy Server restarts whenever a policy changes; give it a minute before you test.

Check your values before installing

From a lolly-work checkout, the preflight script sends every pod the chart would create to the cluster as a server-side dry run, so each admission webhook answers and nothing is created:

helm template lolly-work deploy/helm -n lolly-work -f my-values.yaml \
  | node scripts/kubewarden-preflight.ts --namespace lolly-work --probes

With --probes it also sends nine copies of the control-plane pod, each breaking one rule: a privileged container, an added capability, the root user, a writable root filesystem, the host network, a hostPath volume, an unconfined seccomp profile, an unsigned image and an image outside the list. It prints ADMITTED or REFUSED with the policy's message for each, and exits with status 1 when a Work pod is refused or a probe is admitted.

Options

• The render worker in its own user namespace. After policies.yaml, apply options/render-worker-user-namespace.yaml. It lets the render worker add SYS_ADMIN and SYS_CHROOT, and adds a CEL rule that refuses any pod adding a capability unless it sets hostUsers: false. The capability policy selects the worker by its component label, which anyone who can create pods in the namespace can copy; the CEL rule keeps the two capabilities inside a user namespace even then.
• Your pack and web app images. Add their repositories to the images.allow list of lolly-work-image-sources. Sign them and add a signatures entry to lolly-work-image-signatures if you want them verified too.
• A mirror. Mirrored images have new names. Add the mirrored repositories to lolly-work-image-sources and as image patterns in lolly-work-image-signatures, and copy the signatures with the images (cosign copy, or a registry that serves OCI referrers). The signing identity stays the same.
• hostPath volumes. The set refuses them. A single-node install that needs one should add hostPath to lolly-work-volumes knowingly.

Behaviour of the published policies

Qualifying the set turned up four things about the published policies that shaped it:

• verify-image-signatures reads its prefix setting as url_prefix, although its README shows urlPrefix, and it appends / to the prefix. A prefix ending in refs/tags/v therefore matches nothing, so the set uses https://github.com/lolly-tools/lolly-work/.github/workflows/release.yml@refs/tags/.
• apparmor-psp reads only the container.apparmor.security.beta.kubernetes.io/ annotation. Kubernetes 1.30 and later, and Work's chart, set securityContext.appArmorProfile, which that policy admitted unchecked, so the set uses a CEL rule instead.
• user-group-psp v1.1.5 with validate_only: true refuses MustRunAs even when the ID is present and within range, and checks each container without the pod's own value. The set runs it as a mutating policy.
• A first signature verification fetches Sigstore's trust material and can take longer than the Policy Server's 2-second evaluation limit, so the signature policy sets timeoutEvalSeconds: 10.

Qualification

On 2026-10-27 the set ran on Kubewarden 1.38.2 (admission-controller chart 6.1.0) with K3s 1.35.5 in k3d, on arm64. Work 1.1.2 and its render worker, pinned by digest, were installed with PostgreSQL 17 in a separate namespace and the worker on the Localhost seccomp profile.

When the chart changes

node scripts/kubewarden-requirements.ts --write regenerates the requirements file from the chart. tests/kubewarden-policies.test.ts fails until the requirements match the chart and the policies agree with the requirements, so a chart change that needs a new volume type, capability or profile cannot pass review with the set out of date.