Admission Control Stops Bad Specs, Not Bad Runtime Behavior

01

Runtime Enforcement vs Admission Control, in Short

Admission control judges the request object before Kubernetes stores it, so it can reject an unsafe spec but sees nothing the workload does after the pod starts. Runtime enforcement works on the running workload's behavior, which is the only place the questions about what actually executed can be answered.

The two are not substitutes. The sections below explain where the admission boundary sits and what falls on the runtime side of it.

02

What Admission Control Can Answer Reliably

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.

03

What They Cannot Prove After Scheduling

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.

The runtime threat detection workflow illustrates reviewing process ancestry, workload identity, and event outcomes after startup.

• Admission can block a risky spec, but it cannot confirm whether a code path executed.
• Admission can require a baseline posture, but it cannot explain live process behavior.
• Admission can validate the request, but it cannot scope post-start blast radius on its own.

04

Where Audit Logs Help and Where They Still Stop

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.

05

A Practical Control Split for Kubernetes Teams

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.

For the visibility each collection method provides, see runtime security vs agentless scanning. The platform investigation workflow shows how runtime findings can be reviewed with workload context.

• Preventive layer: reject unsafe specs and enforce platform guardrails.
• Control-plane layer: retain audit records that explain who changed what.
• Behavior layer: collect execution evidence only for incidents, exploitability, and high-value investigations.