Admission control should stop unsafe workloads before they run, while runtime detection should catch the behavior of approved workloads that later become risky. Teams need both because policy checks cannot predict every abuse case and telemetry cannot prevent initial deployment. The right balance is pre-runtime prevention plus continuous post-deploy observation.
What admission control should decide, and what it cannot
Admission control is the gatekeeper. It should block workloads that violate policy before they ever consume cluster resources, for example images that come from untrusted registries, pods that request excessive privilege, or manifests that break baseline security rules. It is strongest when the decision can be made from the submitted object and policy context alone.
That strength is also its limit. Admission control sees intent at deploy time, but it cannot tell whether an approved workload will later be abused, whether a trusted image contains secrets hidden inside container images, or whether a service will behave maliciously after startup. The control is necessary because it prevents obvious bad states, but it is not sufficient because security failures also emerge after scheduling.
Why runtime detection is the second half of the control plane
Runtime detection covers what admission cannot: process launches, network egress, privilege escalation, unexpected file access, shell access in containers, suspicious API calls, and lateral movement after deployment. This is where telemetry becomes the control, because the question is no longer whether the workload should exist, but whether its live behavior matches the approved security posture.
Kubernetes teams should treat runtime detection as a continuous verification layer, not a backup for weak policy. A workload can pass admission and still become unsafe through compromise, misconfiguration drift, or abuse of mounted secrets and credentials. The balance is therefore not “either policy or telemetry,” but policy to reduce the attack surface and telemetry to expose what policy could not predict.
For container-specific hardening and the image-to-runtime risk chain, NIST SP 800-190 Container Security is the clearest external reference for connecting registry, image, orchestrator, and runtime control.
How to balance the two in practice
The practical balance is to make admission control strict on well-defined, high-confidence rules and to make runtime detection broad on behavior that is hard to determine in advance. Admission should block known-bad patterns such as privileged pods, unsafe host access, unsigned or unapproved images where policy requires trust, and deployments that break namespace or network boundaries. Runtime detection should watch for deviations, including privilege gain, unexpected outbound traffic, file tampering, and suspicious process activity.
That division works best when each layer has a different job. Admission should answer, “Should this workload be allowed to start?” Runtime detection should answer, “Is this allowed workload still behaving safely?” Teams that try to force admission to solve every abuse case usually end up with brittle policy sprawl, while teams that rely only on detection discover problems only after exposure has already occurred.
For a detection-oriented view of adversary behaviour after initial access, MITRE ATT&CK Enterprise Matrix helps teams map runtime alerts to privilege escalation, credential access, and lateral movement patterns.
Risk and Threat Considerations
When admission is too permissive, unsafe workloads can enter the cluster with privileges or dependencies that expand blast radius immediately. When runtime detection is too weak, an initially legitimate workload can be repurposed after compromise to steal secrets, open backdoor access, or move laterally across the cluster and connected services.
Failure mechanism: The control failure usually comes from assuming one layer can cover the entire lifecycle. Admission policies miss post-deploy abuse, while runtime tools miss the initial creation of high-risk objects or image-derived exposure.
Impact: The result is either preventable deployment of dangerous workloads or delayed discovery of compromise, both of which increase the chance of credential theft, unauthorized access, and cluster-wide spread.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Kubernetes runtime detection depends on continuous monitoring of workload behavior. |
| AC-6 — Least Privilege | Admission control is used to prevent overly privileged workloads from starting. | |
| Recommendation — Instrument cluster telemetry to detect anomalous runtime activity and suspicious workload behavior. Deny deployments that request unnecessary privilege or broad access. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator Management | Workload admission and runtime controls often protect identities and secrets used by pods. |
| DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Runtime detection in Kubernetes relies on continuous monitoring for unauthorized or unexpected activity. | |
| Recommendation — Enforce controlled lifecycle handling for credentials and access material used by workloads. Continuously monitor cluster activity for unauthorized or unexpected workload behavior. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Admission policies and runtime baselines both enforce secure configuration of container workloads. |
| Recommendation — Standardize secure workload configurations and block unsafe deployment settings. | ||
Practitioner Guidance
What to prioritise: Use admission control for deterministic guardrails that are safe to enforce upfront, then invest runtime detection in the behaviors that are only visible after scheduling. If a rule can be checked from the manifest with high confidence, enforce it early; if it depends on live behavior, observe it continuously.
What to verify: Make sure a blocked deployment is actually blocked, and make sure an approved workload still emits enough telemetry to support detection. A strong program has evidence for both outcomes: policy decisions at admission and usable signals from the running cluster.
Practitioner takeaway: The right balance is not to split control evenly, but to let admission prevent obvious unsafe starts and let runtime detection catch the unexpected ways approved workloads fail, drift, or get abused.
Related resources from NHI Mgmt Group
- How should security teams use Kubernetes admission control without slowing delivery?
- How should security teams turn Kubernetes runtime detection into prevention?
- What is the difference between admission control and runtime security in Kubernetes?
- How do security teams decide between runtime detection and full-stack attack correlation in Kubernetes?