Kubernetes Admission and Policy Boundary

Kubernetes Admission and Policy Boundary refers to the specific limits of what admission control and policy enforcement can actually guarantee about a cluster's state, marking the line between what is verified at the moment an object is submitted and what can change or matter afterward, at runtime, or through paths that never pass through admission at all. Understanding this boundary precisely prevents a false sense of security in which admission-time checks are assumed to guarantee properties they cannot actually enforce continuously.

What Admission Can and Cannot Guarantee

A Point-in-Time Check, Not Continuous Enforcement

Admission control evaluates an object only at the moment of CREATE, UPDATE, DELETE, or CONNECT — it says nothing about the object's state between admission events. A pod that passed validation at creation time can still exhibit runtime behavior inconsistent with the policy's intent if, for example, a process inside the container later attempts privilege escalation through a kernel vulnerability the admission check had no way to anticipate.

Admission Cannot See Inside a Running Container

Validating that a pod's manifest requests runAsNonRoot: true confirms the declared configuration, but admission has no visibility into what the container's actual runtime behavior does once started; a misbehaving or compromised process is a runtime security concern that admission-time policy cannot detect or prevent, only constrain the starting conditions for.

Objects and Paths That Bypass Admission

Direct etcd Access

Admission control is enforced entirely within the API server's request handling; any path that writes directly to etcd, bypassing the API server (a scenario relevant primarily to control-plane compromise or misconfigured direct etcd access), completely bypasses every admission check regardless of how comprehensively they are configured.

Pre-Existing Objects

Applying a new or stricter policy affects only future CREATE and UPDATE requests; objects that already exist in the cluster are not retroactively re-evaluated, meaning a newly enforced policy can coexist with already-running non-compliant workloads until those workloads are next modified or redeployed.

Resources Outside Admission Rule Scope

A webhook or ValidatingAdmissionPolicy only evaluates the specific resource types, operations, and namespaces its rules match; any resource type not covered by a matching rule passes through admission entirely unevaluated, regardless of how thorough the policy coverage for other resource types might be.

The Boundary Between Admission and Other Enforcement Layers

Admission Versus RBAC

Admission and RBAC operate on different questions: RBAC determines whether a caller is authorized to perform an operation at all, while admission determines whether the specific object being submitted satisfies configured requirements — a caller can be fully authorized by RBAC and still have their request rejected by admission, and conversely admission cannot substitute for RBAC in restricting who may act.

Admission Versus Runtime Security Controls

Runtime security tooling — seccomp enforcement, container runtime sandboxing, network policy, intrusion detection — operates continuously after a pod is running, catching or constraining behavior that admission-time validation of the manifest could never have anticipated; a comprehensive security posture requires both layers, since admission alone cannot compensate for the absence of runtime controls.

Practical Implications for Security Design

Combining Admission With Continuous Compliance Scanning

Because admission does not retroactively evaluate existing objects, periodic scanning of already-running workloads against current policy (using tools that inspect live cluster state rather than only intercepting new submissions) closes the gap left by objects that predate a policy's introduction or a policy's tightening.

kubectl get pods --all-namespaces -o json | \
  conftest test --policy current-policies/ -

Recognizing Admission as One Layer, Not a Complete Defense

A security review that treats "we have admission policies enforcing X" as equivalent to "X cannot happen in this cluster" overstates what admission control actually guarantees; framing admission correctly as the boundary it actually enforces — validation of new and modified objects passing through the standard API path — clarifies what additional controls are needed to address the gaps admission structurally cannot close.

Defense in Depth Across the Full Lifecycle

Effective policy design treats admission control as the earliest of several checkpoints across a workload's lifecycle — build-time scanning, admission-time validation, and runtime monitoring together — rather than relying on any single layer, including admission, to fully enforce a security property on its own.