Workload Guardrails

This page is the reference for Lumie's application-layer workload guardrails. It covers the checked-in safety rails that sit between a Helm values file and a running workload: PodDisruptionBudgets, namespace-level NetworkPolicies, audit-mode Kyverno policies, and the Goldilocks-adjacent labels that still appear in manifests.

Source Paths

Path	Role
lumie-infra/charts/common/values.yaml	Shared workload defaults, including resource shape, security context, rollout strategy, and optional PDB settings
lumie-infra/charts/common/templates/pdb.yaml	Shared PDB rendering contract
lumie-infra/applications/lumie/backend/common-values.yaml	Backend opt-in for PDB, resource requests, and security context
lumie-infra/applications/lumie/frontend/common-values.yaml	Frontend opt-in for PDB, resource requests, and security context
lumie-infra/applications/lumie/worker/grading-svc/common-values.yaml	Worker opt-in for PDB, resource requests, and security context
lumie-infra/applications/lumie/{backend,frontend,worker/grading-svc,develop}/manifests/network-policy.yaml	Default-deny plus explicit-allow NetworkPolicy sets
lumie-infra/security/kyverno/argocd.yaml	ArgoCD application for the Kyverno controller and local policy set
lumie-infra/security/kyverno/manifests/policies/*.yaml	Checked-in validation and mutate policies
lumie-infra/security/kyverno/manifests/policy-exceptions.yaml	Explicit exceptions for bootstrap, Falco, Tekton DinD, and CNPG
lumie-infra/observability/goldilocks/argocd.yaml	Goldilocks application definition kept in repo
lumie-infra/observability/kustomization.yaml	Active observability root that currently leaves Goldilocks disabled

Guardrail Layers

Layer	Where it lives	What it does today
Shared chart defaults	charts/common/values.yaml	Defines the baseline shape for resources, security context, rollout strategy, affinity, and optional PDBs
Per-application opt-in	applications/lumie/**/common-values.yaml	Turns individual guardrails on or tunes them per workload
Namespace NetworkPolicy	applications/lumie/**/manifests/network-policy.yaml	Enforces default-deny plus explicit dependency allows
Admission policy	security/kyverno/manifests/**	Audits image registry, security context, and resource policy; mutates CPU limits away at admission
Recommendation labels	goldilocks.fairwinds.com/enabled labels in ArgoCD manifests	Present in manifests, but Goldilocks itself is not in the active observability root

PodDisruptionBudget Contract

The shared PDB template is intentionally maxUnavailable-based.

Representative excerpt:

spec:
  maxUnavailable: {{ $comp.podDisruptionBudget.maxUnavailable | default 1 }}

The template comment explains why: minAvailable: 1 can deadlock node drains when a KEDA-managed workload is down to one replica.

Current opt-in is narrow and explicit:

Workload	PDB state	Source
lumie-backend	enabled, maxUnavailable: 1	applications/lumie/backend/common-values.yaml
lumie-frontend	enabled, maxUnavailable: 1	applications/lumie/frontend/common-values.yaml
grading-svc	enabled, maxUnavailable: 1	applications/lumie/worker/grading-svc/common-values.yaml

Do not assume every workload inherits a PDB. The common chart only renders one when the application values opt in.

NetworkPolicy Contract

Lumie uses namespace-level default-deny policies with explicit allow lists.

The active checked-in coverage is:

• lumie-dev: shared dev namespace guardrails
• lumie-backend: default-deny plus explicit ingress and egress for Postgres, RabbitMQ, Redis, MinIO, Vault, workers, DNS, HTTPS, Traefik, cert-manager, and frontend
• lumie-frontend: default-deny plus backend, Vault, DNS, HTTPS, Traefik, and cert-manager
• lumie-worker: namespace-wide worker guardrail anchored in grading-svc, using podSelector: {} so it covers every worker pod in lumie-worker

Important current-state details:

• production Traefik is expected in kube-system, not a dedicated traefik namespace
• the worker policy is intentionally a union of every worker dependency
• HTTPS egress still uses 0.0.0.0/0 because the checked-in policy model does not have FQDN-aware egress

That last point is design, not omission. Do not rewrite it in docs as a hidden allow-list.

Kyverno Contract

Kyverno is part of the workload guardrail story, but it is not the primary blocking layer today.

The active checked-in policies are:

Policy	Current mode	Effect
require-zot-registry	Audit	Flags container or init-container images outside zot.lumie-infra.com
require-security-context	Audit	Flags missing runAsNonRoot, privileged containers, and privilege escalation
require-resource-limits	Audit	Flags missing memory requests or limits, missing CPU requests, and the presence of CPU limits
remove-cpu-limits	mutate on admission only	Removes CPU limits from admitted pods

Policy exceptions are checked in and broad enough to matter operationally:

• bootstrap namespaces such as argocd, cert-manager, external-secrets, vault, and zot
• Falco pods
• Tekton DinD springboot-test task pods
• CNPG cluster and pooler pods

Goldilocks-Adjacent State

The manifest labels still advertise goldilocks.fairwinds.com/enabled: 'true' on many ArgoCD-managed namespaces and applications, but the active observability root comments out:

• goldilocks/argocd.yaml
• vpa/argocd.yaml
• blackbox-exporter/argocd.yaml

Treat that label as dormant metadata today, not as proof that recommendation or VPA guardrails are active in-cluster.

Operational Failure Modes

Failure mode	What usually drifts
Drains evict too much or too little	application values forgot to opt into the shared PDB template, or a rollout strategy change conflicts with the expected maxUnavailable behavior
A workload is Healthy in ArgoCD but cannot reach a dependency	the NetworkPolicy allow list is incomplete for the namespace even though the pod spec itself is valid
Admission logs show violations but deploys still succeed	the policy is intentionally Audit and does not block creation
A label suggests autosizing advice exists but no recommendations appear	Goldilocks is disabled in the active observability root
CPU limits keep disappearing	that is the expected mutate behavior from remove-cpu-limits, not arbitrary chart drift

Verification

cd /Users/bluemayne/Projects/Lumie
rg -n "podDisruptionBudget:|maxUnavailable: 1" \
  lumie-infra/applications/lumie/*/common-values.yaml

rg -n "default-deny-all|allow-egress-postgres|allow-egress-rabbitmq|allow-egress-vault|allow-egress-https|allow-ingress-from-traefik" \
  lumie-infra/applications/lumie/{backend,frontend,worker/grading-svc,develop}/manifests/network-policy.yaml

rg -n "validationFailureAction|require-zot-registry|require-security-context|require-resource-limits|remove-cpu-limits" \
  lumie-infra/security/kyverno/manifests

kubectl get poddisruptionbudgets -A
kubectl get networkpolicy -A
kubectl get clusterpolicy
kubectl get policyexception -n kyverno

Success means the checked-in PDB opt-ins match the live objects, default-deny policies exist in the guarded namespaces, and Kyverno still exposes the documented audit-mode policy set and exceptions.