Guides: Installing Under an Admission Policy

Add site-required labels and annotations to every object the DevZero charts create, so clusters running OPA Gatekeeper or Kyverno admit them.

Many platform teams run an admission controller that rejects any object missing a set of required labels — a cost centre, a service owner, a tier. OPA Gatekeeper and Kyverno are the common ones. On such a cluster a Helm chart that cannot set those labels does not install at all.

The DevZero charts accept four values for this. Each defaults to {}, so an install that does not need them is unaffected.

The values

Value	Applies to
`commonLabels`	Every object and every pod template
`commonAnnotations`	Every object and every pod template
`podLabels`	Pod templates only, on top of `commonLabels`
`podAnnotations`	Pod templates only, on top of `commonAnnotations`

helm upgrade --install dakr oci://registry-1.docker.io/devzeroinc/dakr-operator \
  --version 0.2.19 \
  --namespace devzero-system --create-namespace \
  --set commonLabels.cost_center=platform \
  --set commonLabels.service_tier=infra

Or in a values file, which is easier when the keys contain dots:

commonLabels:
  example.com/cost-center: platform
  example.com/tier: infra

commonAnnotations:
  example.com/owner: platform-team

Why labels reach the pod template too

commonLabels and commonAnnotations are applied to the pod template as well as the owning Deployment or DaemonSet. This is deliberate.

Gatekeeper's expand-workloads feature evaluates constraints against the Pod a workload would create, not only the workload object itself. A Deployment whose own metadata satisfies a policy can still be denied on its pod spec, so labelling the workload alone is not enough.

Use podLabels and podAnnotations when you want metadata on the pods but not on the objects that own them — a scrape annotation, for instance.

Covering a whole release

Helm values are scoped to the chart they are set on. The zxporter chart bundles zxporter-nodemon as a subchart, and a chart-local commonLabels set on the parent does not reach it.

Set the values under global to cover every chart in the release:

global:
  commonLabels:
    example.com/cost-center: platform

A chart-local value still applies on top and wins if the same key is set in both places.

If a policy denies only some of the objects an install creates, a chart-local value is the usual cause. Move it under global.

Keys the charts own

Some keys carry meaning the chart depends on, so a value you supply for one of them is ignored rather than applied:

app.kubernetes.io/*, helm.sh/*, app, control-plane
Selector labels — these are immutable after an object is created, and changing one would break helm upgrade on an existing release
Config checksums, kubectl.kubernetes.io/default-container, and the operator's own runtime annotations

This is what keeps the values safe to set on a release that is already running: with all four unset, the charts render exactly as they did before, and a key collision can never rewrite chart state.

Chart support

Chart	Operator	Support	Available from
`dakr-operator`	Write Operator, Scheduler	All four values, plus `global`	0.2.19
`zxporter`	Read Operator	All four values, plus `global`	0.1.17
`zxporter-nodemon`	Read Operator (node agent)	All four values, plus `global`	0.1.17
`zxporter-netmon`	Network Operator	All four values, plus `global`	0.1.17
`karpenter` (dzkarp)	Node Operator	Upstream knobs: `additionalLabels`, `additionalAnnotations`, `podLabels`, `podAnnotations`	—
`dakr-security`	Security Operator	Per-component knobs: `operator.labels`, `operator.podLabels`, `operator.annotations`, `trivy.podLabels`	—

Helm accepts unknown values without complaint, so --set commonLabels... is silently ignored rather than rejected wherever it is not understood.

On the first four charts, that means the installed release predates the version in the table — check it with helm list -n devzero-system. On karpenter and dakr-security it means the value does not exist at any version: use the knobs in their rows instead. Upgrading those two will never make commonLabels work.

What is not covered

Custom Resource Definitions. The CRDs the charts install are generated by controller-gen or vendored from upstream, so they carry no chart templating and do not receive these labels. If your constraint matches CustomResourceDefinition, exempt that kind:

spec:
  match:
    excludedResources: ["customresourcedefinitions.apiextensions.k8s.io"]

The script installer. The curl-based zxporter installer applies a pre-rendered manifest bundle and has no values file. On a cluster with a required-label policy, install the Helm charts instead.

Exempting the namespace instead

If you would rather not label the objects, exempt the DevZero namespace from the constraint:

spec:
  match:
    excludedNamespaces: ["devzero-system"]

This also covers constraints that DevZero cannot satisfy through labels at all — a required-probe or read-only-root-filesystem rule, for example. Check with whoever owns your admission policy before doing this: it removes every constraint from that namespace, not just the label one.

Installing Under an Admission Policy