Kubernetes Security Baseline Enforcement Workflow
Adopt a hardening baseline for workloads, enforce it with admission policy, and audit exceptions with expiring waivers.
Objective
Bring every workload to a declared hardening baseline (no privilege, readonly roots, capped resources) with automated enforcement instead of review hope.
Environment
- A Kubernetes cluster with admission controller capability
- A baseline standard chosen (NSA/CISA, CIS, or Pod Security Standards)
- Manifests or Helm charts for existing workloads
Steps
1. Choose and write down the baseline
Select a baseline and translate it into concrete rules: no host namespaces, no privileged, runAsNonRoot, seccomp, dropped capabilities, resource limits.
Expected state: A written rule list exists that both humans and policy engines can read.
2. Audit current state against it
Scan all running workloads for baseline violations, ranked by exposure (internet-facing first), producing the remediation backlog.
Expected state: A violation inventory exists with workload, rule, and severity.
3. Enforce at admission for new work
Deploy the policy engine in audit mode first, then enforce for new deployments so violations cannot enter fresh.
Expected state: A violating manifest is rejected at apply time with a named rule.
4. Remediate the backlog by exposure
Fix existing violations in exposure order, using the same rule names as the policy for traceability.
Expected state: The violation count declines monotonically, internet-facing reaching zero first.
5. Waiver exceptions with expiry
For workloads that genuinely need an exception (host network for the ingress controller), register a waiver with owner, justification, and expiry, audited monthly.
Expected state: Every exception is registered, owned, and expires; none are silent.
Expected outcome
A cluster where the hardening baseline is enforced at admission, the legacy backlog is burned down by exposure, and exceptions are registered, owned, and mortal.
Verification
Applying a privileged pod is rejected by admission with the rule named; the waiver register shows zero expired entries; the violation inventory is empty or all-waived.
Baselines fail at the review stage; enforce at admission
A hardening document checked in code review blocks only the violations a tired reviewer notices. Encoding the same baseline as admission policy blocks all of them at apply time, and the backlog burn-down makes the legacy estate converge.
baseline (PSA restricted + house rules):
no privileged, no hostNetwork/hostPID
runAsNonRoot, seccomp: RuntimeDefault
capabilities: drop ALL, allowlist per workload
resources: limits required
readOnlyRootFilesystem: true (waiver-able)
admission: enforce on new deploys, audit on old
apply privileged pod -> REJECTED
"violates baseline: privileged=true (rule B2)"
backlog: 47 violations (12 internet-facing)
burn-down: internet-facing zero by week 2
waivers: 3 registered (ingress hostNetwork,
owner: net-team, expires 2027-01, reviewed monthly)Audit mode before enforcement mode
Turning enforcement on immediately blocks deploys for violations nobody catalogued, creating a standoff between security and delivery. Running the policy in audit first enumerates the blast radius, sequences the burn-down, and makes the enforcement flip a non-event.
Waivers are the honesty mechanism
Every real cluster has legitimate exceptions: the ingress controller needs hostNetwork, some legacy sidecar needs writable rootfs. Registering these with owner and expiry keeps the baseline honest; pretending they do not exist leads to a global disable the first time someone needs one.