Pod Security Admission, CEL policies, and admission webhooks can reject unsafe manifests before they land in etcd. They still do not tell you what a workload executed after startup, which is why platform teams should separate preventive policy from runtime evidence.
Senior Platform Engineer
Admission control is where Kubernetes decides whether an API request may persist. That makes it excellent for preventing known-bad configuration, but insufficient for proving what a running workload actually did after the pod started.
Admission controllers evaluate create, update, delete, and connect requests on the Kubernetes API before the final object is stored. That gives platform teams a strong place to enforce non-root defaults, approved registries, label requirements, or namespace-level Pod Security standards.
This boundary matters because the control plane is only judging the request object. Pod Security Admission, ValidatingAdmissionPolicy, and admission webhooks are therefore best used for configuration intent: what the workload asked Kubernetes to run and whether that request matches cluster policy.
Once a pod is admitted and scheduled, runtime risk shifts from object validation to workload behavior. Admission controls do not observe process lineage, loaded libraries, outbound connections, file access, or whether a vulnerable code path actually executed under production traffic.
That is why an admitted manifest can still produce unsafe outcomes later. A container may stay within an allowed security context and still initiate suspicious network activity, spawn an unexpected child process, or exercise a reachable package vulnerability that never appeared risky from the manifest alone.
Kubernetes audit logs answer a different set of questions: who changed cluster state, when the request happened, which resource was targeted, and how the API server handled it. That is essential evidence for control-plane investigations, policy exceptions, and post-incident review.
Audit records still stop at the API boundary. They can show that a Deployment was created, patched, or deleted, but not which function executed inside the container afterward or whether a process chain crossed from one service into another. For investigations, audit is necessary context, not complete runtime evidence.
The clean operating model is to separate preventive checks from behavioral observation. Use admission controls to reject deterministic mistakes before deploy, use audit policy to preserve control-plane history, and use runtime telemetry for the questions that only execution can answer.
In practice, teams get the best result when they start with built-in controls first: Pod Security Admission for broad guardrails, CEL-based policies for simple validation, and narrow webhook scope only where external logic is unavoidable. That keeps policy latency low and reduces the chance that a broken webhook becomes a cluster availability problem.
Kubernetes Documentation
Kubernetes Documentation
Kubernetes Documentation
Kubernetes Documentation
Kubernetes Documentation
NIST
Read Next
Engineering
We instrumented 14 production clusters across three cloud providers to measure the real CPU and memory cost of eBPF-based runtime telemetry. Here is what we found — and where the numbers get interesting.
Read article
Security
A CVE with a 9.8 score that never executes in your environment is less dangerous than a 5.3 that runs on every request. We built a scoring model around this idea.
Read article
Incident Response
Traditional incident scope relies on logs, alerts, and educated guesses. Execution graphs change that. We walk through a real incident timeline and show the difference.
Read article
