Kubernetes Security Architecture That Holds (2026)

Q: What are the four control planes of Kubernetes security?

Kubernetes security decomposes into four enforcing planes that map to four distinct stages of an attack. First, admission control runs at the API server on every create or update and stops an insecure workload from ever being persisted — a privileged pod, a hostPath mount, a pod with no securityContext, an unsigned image. Second, identity and RBAC run on every API request and stop a workload from asking the API server for more than its job requires, so a single stolen service-account token cannot read every secret in the cluster. Third, the network plane stops a compromised pod from moving laterally or exfiltrating data, because Kubernetes defaults to an allow-all network where one foothold can reach every service. Fourth, runtime detection watches syscalls at the kernel and catches — or at least sees — the exploit that beat the first three, such as a container escape or a reverse shell. They are defence in depth in the literal sense: each plane assumes the one before it failed. The most common mistake is investing entirely in the first plane, scanning images and linting manifests, while leaving the other three empty, which leaves a cluster that audits clean and is one container escape from a cluster-wide incident.

Q: Why is a passing image scan and CIS benchmark not enough for Kubernetes security?

Because a scan and a benchmark describe the state of your configuration at rest, and cluster security is decided at three moments the scanner never observes: what admission control lets into the cluster, what the network lets a compromised pod reach, and what the runtime does when a pod starts behaving unlike itself. A CIS score and a clean image scan are necessary hygiene, but they are a snapshot of intent, not a control that acts during an attack. An attacker does not exploit your Markdown or your benchmark score; they exploit a pod that was admitted with a hostPath mount, a flat network that lets a single foothold reach every service, and a node with no runtime sensor to notice a shell spawning inside a container that has only ever run a JVM. The uncomfortable pattern in most breach post-mortems is not a missing scanner — it is a cluster that scanned clean and had no enforcing control between the initial foothold and the entire estate. Scanning belongs in your pipeline as hygiene, but it must be treated as an input to security posture, never as the posture itself. The controls that actually stop an incident live at admission, on the network, and at runtime, and none of them is something a scanner can provide.

Q: What is the difference between Pod Security Admission and a policy engine like Kyverno or Gatekeeper?

They are two layers of the same admission plane, and confusing them leaves gaps. Pod Security Admission is the built-in successor to the removed PodSecurityPolicy; it enforces the three Pod Security Standards — privileged, baseline, restricted — as a per-namespace label, and it is free, always-on, and the correct security floor. Labelling your workload namespaces restricted already blocks privileged containers, host namespace sharing, most hostPath mounts, and running as root, which are the exact primitives a container escape needs. But Pod Security Admission is deliberately coarse: three fixed tiers, no custom logic, and no ability to check image provenance. A policy engine like Kyverno or OPA Gatekeeper covers the rules Pod Security Admission cannot express — images must come from an approved registry, every pod must carry a team label, no latest tags, the image must have a valid signature. That is where you enforce supply-chain provenance at deploy time. The correct architecture uses both: Pod Security Admission as the always-on floor, and a policy engine layered on top for organisation-specific and provenance rules. Run the policy engine in audit mode first, watch what it would have blocked for a week, then flip to enforce — going straight to enforce is the fastest way to reject a legitimate deploy and get the whole policy layer switched off by an angry team.

Q: Why is the Kubernetes network the most commonly skipped security plane?

Because it takes deliberate work to close and Kubernetes gives you no warning that it is open. Kubernetes ships with an allow-all network by default: every pod can talk to every other pod and to the internet unless a NetworkPolicy explicitly says otherwise. That default is silent — nothing breaks, everything works, and the gap is invisible until an incident. It is also the single mechanism of lateral movement: once an attacker has a foothold in one pod, a flat network lets them reach every service, every database, and every namespace, turning a contained compromise into a cluster-wide breach. Namespaces do not help here, because a namespace is not a network boundary without policy — believing otherwise is isolation theatre. The correct design is default-deny for both east-west and egress traffic, then allowlist explicitly: a payments pod should reach the database and the payment gateway and nothing else, not the internet, not the analytics namespace, not the API server unless it genuinely calls it. Native NetworkPolicy covers L3 and L4, and a CNI like Cilium adds identity-aware L7 rules and DNS-based egress control, which is what actually stops exfiltration to an attacker-controlled domain. Egress control specifically is the policy nobody writes, and it is the one that turns a data theft into a blocked connection visible in your flow logs.

Q: What does runtime security detection add that admission and network policy cannot?

Runtime detection is the sensor of last resort for workloads whose manifest was fully compliant but whose behaviour at execution is malicious. Admission control validates the spec before the pod runs, and network policy constrains what it can reach, but neither can catch an exploit that operates entirely inside an admitted, compliant container. A pod that has only ever executed a Java process suddenly spawning a shell, a process reading /etc/shadow, an outbound connection to a mining pool — these are behaviours no static control can predict because the manifest that created the pod was clean. eBPF-based sensors and Falco watch syscalls at the kernel level and alert or kill on drift from the expected behaviour of that workload. This is the plane that sees a container escape in progress. The critical caveat is that runtime detection is only useful if the signal reaches a pipeline that acts on it: deploying Falco and routing its output to a dashboard nobody watches is a cost centre, not a control. Cluster runtime events belong in the same reviewed, tested, versioned detection estate you run for the rest of your security telemetry, with an on-call and automated response playbooks such as pod-kill and node-cordon. A good operational target is alert-to-triage under five minutes for a container-escape signature; slower than that and the attacker dwell time wins the race.

Q: What are the most common Kubernetes security anti-patterns?

Six recur across audited-but-indefensible clusters. First, security-by-scanner: treating a green image scan and a CIS score as the security posture when they are only hygiene inputs and none of them acts at admission, on the network, or at runtime. Second, leaving the allow-all network as default: the single biggest lateral-movement enabler, because Kubernetes does not deny pod-to-pod traffic unless you tell it to, so having namespaces is not isolation. Third, binding service accounts or CI to cluster-admin for convenience, so one stolen token owns the entire cluster — the same entitlement-sprawl problem as in cloud IAM, just inside the cluster. Fourth, shipping a policy engine like Kyverno or Gatekeeper straight to enforce with no audit soak, which blocks a legitimate deploy, erodes trust, and gets the policy layer switched off. Fifth, deploying runtime sensors like Falco with no owner, so the alerts land nowhere and a detection nobody triages is noise. Sixth, running mutable, unsigned images and latest tags, so you cannot prove the running image is the one you built and a supply-chain attack lands silently. Every one of these traces to the same root cause: security was documented at rest rather than enforced at runtime, and the attacker only interacts with what the cluster actually enforces.

Q: Should a policy engine be deployed in enforce mode immediately?

No — deploy it in audit mode first, soak for at least a week, review everything it would have blocked, and only then flip specific policies to enforce. A policy engine like Kyverno or OPA Gatekeeper turned straight to enforce is the fastest way to page yourself at 2 a.m. because a legitimate, business-critical deploy was rejected by a rule you had not fully validated. The damage from that is not just the one blocked deploy; it is the loss of trust in the platform, which typically ends with a frustrated team getting the entire policy layer disabled — leaving you worse off than before, because now you have no admission enforcement and a political fight about re-enabling it. The disciplined rollout is to run each new policy in audit mode, where it logs what it would have blocked without actually blocking, then examine those logs against real deploys to find the false positives and the legitimate exceptions. Fix the policies or add the exceptions, communicate the upcoming enforcement to the teams affected, and then promote the policy to enforce. This audit-then-enforce cadence applies to every plane of Kubernetes security that can reject a workload, and it is the difference between a policy layer that teams rely on and one they route around. Prevention controls only work if they are trusted enough to stay switched on.

Q: How should Kubernetes security maturity be sequenced?

Sequence the planes so prevention comes before detection, because an enforced admission floor and a default-deny network are worth more than any amount of runtime tooling bolted onto an open cluster. Level 0 is scanned: image scanning and CIS benchmarks in CI, which is necessary hygiene and zero runtime enforcement — most teams that claim to do Kubernetes security stop here. Level 1 is an admission floor: every workload namespace labelled Pod Security restricted, so privileged pods, host mounts and root containers can no longer be created; it is free and the highest single return available. Level 2 is policy as code: Kyverno or Gatekeeper in enforce mode after an audit soak, adding registry allowlists, required labels, and signed-image verification, so provenance is enforced at deploy rather than hoped for. Level 3 is a default-deny network: east-west and egress denied by default and allowlisted per workload, with DNS-aware egress control, so lateral movement and exfiltration require defeating an explicit control instead of exploiting a default. Level 4 is runtime detection wired to response: eBPF and Falco sensors feeding a detection pipeline with an on-call and automated pod-kill and node-cordon playbooks, so the cluster sees and contains the exploit that beat the first three planes. The through-line is that security lives in what the cluster enforces at runtime, not in what a document asserts at rest.

Satyam Kumar

Back to Blog

ai-architecture

Kubernetes Security Architecture: Admission, Runtime, and Network Policy That Hold

By Satyam KumarAugust 27, 202611 min read

kubernetes security admission control pod security standards pod security admission kyverno opa gatekeeper network policy cilium ebpf falco runtime security container escape rbac defense in depth cloud native security 2026

Kubernetes Security Architecture: Admission, Runtime, and Network Policy That Hold

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

Kubernetes Security Architecture: Admission, Runtime, and Network Policy That Hold

Frequently Asked Questions

Share this article

Comments

Leave a comment