This is unreleased documentation for Admission Controller 1.38-dev.

Using Kubewarden Admission Controller with OpenChoreo

OpenChoreo is an internal developer platform built on Kubernetes. Its control plane turns component abstractions into ordinary Kubernetes manifests and applies them to a separate data plane cluster.

Kubewarden Admission Controller runs in that data plane and validates those manifests as it would any others. By the time a resource reaches admission nothing about it is specific to OpenChoreo, so policies from Artifact Hub work unchanged and there are no OpenChoreo-specific policies to write.

Prerequisites

An OpenChoreo 1.2.x installation with a data plane cluster
kubectl configured against the data plane cluster
Helm v3

Install Admission Controller on the data plane

Install into the cluster running the OpenChoreo data plane, not the control plane.

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

helm upgrade --install kubewarden kubewarden/admission-controller \
  --namespace kubewarden --create-namespace \
  --wait

Confirm the policy server is running before creating policies:

kubectl get policyservers
kubectl get pods -n kubewarden

Scope policies to OpenChoreo namespaces

A ClusterAdmissionPolicy applies to the whole cluster unless you scope it. The data plane also runs OpenChoreo’s own components, and in a single-cluster quick start it runs the control plane there too. An unscoped, restrictive policy governs all of them and can stop OpenChoreo from working.

For each project and environment, OpenChoreo creates a cell namespace in the data plane and labels it:

Label Value

Label	Value
`openchoreo.dev/managed-by`	`renderedrelease-controller`
`openchoreo.dev/namespace`	Namespace the project belongs to
`openchoreo.dev/project`	Project name
`openchoreo.dev/environment`	Environment name

openchoreo.dev/managed-by

renderedrelease-controller

openchoreo.dev/namespace

Namespace the project belongs to

openchoreo.dev/project

Project name

openchoreo.dev/environment

Environment name

Select those namespaces with matchExpressions. Keep openchoreo.dev/managed-by in every selector, so a policy only reaches namespaces OpenChoreo created:

namespaceSelector:
  matchExpressions:
    - key: openchoreo.dev/managed-by
      operator: In
      values: ["renderedrelease-controller"]
    - key: openchoreo.dev/environment
      operator: In
      values: ["production"]

Dropping the second expression widens the policy to every OpenChoreo cell namespace; adding openchoreo.dev/namespace and openchoreo.dev/project narrows it to a single project.

Promote a policy with the project

A ClusterAdmissionPolicy is applied directly by a platform engineer and takes effect immediately. A namespaced AdmissionPolicy declared inside an OpenChoreo ProjectType is delivered instead to the cell namespaces of every project built on that type, and is promoted between environments along with the project rather than applied to each one separately.

Use cluster-wide policies for guardrails that must hold everywhere, and ProjectType policies for a baseline that belongs to the project definition.

Where results appear

A policy in protect mode fails the apply, and the reason reaches the OpenChoreo component’s ReleaseBinding and its Deploy tab in the portal:

admission webhook "clusterwide-openchoreo-no-latest-tag.kubewarden.admission"
denied the request: not allowed, reported errors: tags not allowed: latest

The rejected resource keeps its previous version, so a blocked deployment does not take a running workload down.

A policy in monitor mode does not reach OpenChoreo, because the apply succeeds. Those violations appear in the audit scanner reports on the data plane.

Full guide

The OpenChoreo project maintains this integration, including ready-made policies, custom label scoping and a sample ProjectType carrying a baseline policy: