Skip to main content

Kyverno

Kyverno is the cluster admission guardrail for Lumie. The repo uses the upstream chart for the admission controller and keeps the policy set in checked-in YAML files under security/kyverno/manifests/.

Responsibility​

  • Run the Kyverno admission controller.
  • Mutate incoming pod specs where the checked-in policy set says to do so.
  • Keep validation policies in Audit mode for admission-time visibility without blocking workload creation.
  • Publish admission-controller metrics to Prometheus.

Source paths​

PathRole
lumie-infra/security/kyverno/argocd.yamlArgoCD Application targeting namespace kyverno
lumie-infra/security/kyverno/helm-values.yamlAdmission-controller image, resources, metrics, and cluster-wide filters
lumie-infra/security/kyverno/kustomization.yamlAdds the local policy files on top of the chart
lumie-infra/security/kyverno/manifests/policies/require-zot-registry.yamlAudit policy for image provenance
lumie-infra/security/kyverno/manifests/policies/require-security-context.yamlAudit policy for non-root and privilege settings
lumie-infra/security/kyverno/manifests/policies/require-resource-limits.yamlAudit policy for memory and CPU requests and no CPU limits
lumie-infra/security/kyverno/manifests/policies/remove-cpu-limits.yamlAdmission-time mutation that removes CPU limits from pods
lumie-infra/security/kyverno/manifests/policy-exceptions.yamlExplicit carve-outs for bootstrap namespaces, Falco, Tekton DinD, and CNPG

Policy surface​

The checked-in policies are intentionally conservative:

  • every validation policy in this folder uses validationFailureAction: Audit;
  • remove-cpu-limits is the only checked-in mutate rule and runs only on admission, not background reconciliation.

That means the current Kyverno contract is visibility and normalization at admission time, not hard blocking or background reporting.

Runtime flow​

Important implementation details​

  • Helm is configured with crds.install: false. The repo expects Kyverno CRDs to exist already and documents manual CRD installation in the values file comments.
  • The chart excludes system namespaces and high-churn resource kinds through config.resourceFilters.
  • Only the admission-controller ServiceMonitor is active. Background, cleanup, and reports controllers are disabled for the 6Gi node footprint plan.

Failure behavior and operational risks​

  • Missing CRDs or a CRD/version mismatch can leave the ArgoCD app synced but the policy objects un-applied or skipped at dry-run time.
  • Because validation is audit-only, policy violations can still be admitted.
  • The PolicyException objects are broad by design in a few cases, especially the Tekton DinD exception, so review them carefully before adding more carve-outs.
  • The image-registry policy checks only containers and init containers and uses namespace exclusions; bootstrap namespaces remain outside the guarantee.

Observability​

  • Kyverno exposes admission-controller metrics through a ServiceMonitor.
  • Policy effectiveness is visible through admission logs and metrics, not background PolicyReports.
  • ArgoCD health confirms controller availability, not policy correctness.

Verification​

kubectl get applications.argoproj.io -n argocd kyverno
kubectl get deploy,pods -n kyverno -l app.kubernetes.io/instance=kyverno
kubectl get clusterpolicy
kubectl get policyexception -n kyverno
kubectl logs -n kyverno -l app.kubernetes.io/instance=kyverno --all-containers --tail=200

Success signals:

  • The kyverno Argo CD application is Healthy and Synced.
  • The Kyverno namespace shows one ready kyverno-admission-controller deployment.
  • kubectl get clusterpolicy returns the checked-in audit and mutate policies instead of failing from missing CRDs.
  • kubectl get policyexception -n kyverno returns the checked-in carve-outs for bootstrap, Falco, Tekton DinD, and CNPG.