To build secure, resilient infrastructure, we need to reset the conversation. Namespaces are valuable, but they don’t isolate.
Kubernetes namespaces are one of the most familiar tools in the platform engineer’s toolkit. In an article published on The New Stack, namespaces were presented as a step-by-step guide to achieving container isolation, a perspective that reflects how many teams use them today.
The term “isolation,” however, is doing a lot of heavy lifting in that framing. Namespaces deliver logical separation, but they don’t enforce the kind of hardened boundaries that stop workloads from interfering with one another at runtime.
This distinction isn’t just semantic — it’s architectural. And in today’s world of multitenant clusters, AI-driven workloads and GPU sharing, it’s a distinction that determines whether your cluster can withstand a breach or collapse like a house of cards.
Namespaces provide developers and operators with an elegant abstraction: They let multiple teams or tenants share a cluster without stepping on each other’s resources. They enforce quotas, enable role-based access control (RBAC), and allow policies to be scoped more cleanly. This is invaluable in reducing administrative chaos.
But namespaces don’t change the fundamental fact that all containers running on the same node share the same kernel. A compromised container in one namespace still has the potential to attack the kernel, exploit shared devices or snoop on GPU memory because the kernel itself is the shared surface.
Amber Wolf’s piece on namespace boundaries underscores this point with real-world examples. When a tenant admin is given full namespace control, they often still retain avenues to affect the entire cluster. Red-team experience shows namespace boundaries don’t hold under pressure. They are policy constructs, not security barriers.
This distinction matters because we often talk about namespaces and isolation as if they’re interchangeable. They aren’t. Namespaces provide partitioning. Isolation is about constraining workloads so tightly that even if one is compromised, it cannot reach across boundaries.
The limitations of namespaces show up starkly in modern attack patterns. Container escapes and kernel-level vulnerabilities illustrate the problem:
Security models that treat namespaces as hardened boundaries are leaning on a dangerous misconception: that logical separation equals runtime isolation. The moment a container breaks into the kernel, all bets are off.
It’s worth remembering that virtualization solved this problem decades ago. Virtual machines (VMs) enforced hard boundaries by giving each workload its own kernel. One VM couldn’t trivially interfere with another. Containers traded this away for speed, density and agility — and those trade-offs were rational at the time.
But times have changed. Lightweight virtualization and hypervisor-backed runtimes have eroded the performance gap that once made VMs less appealing. Paravirtualization and type-1 hypervisors now offer near-native performance while restoring the strong isolation properties that namespaces lack.
Apple recently validated this approach with its new Container Framework, which runs containers inside VM-backed boundaries. Projects like Kata Containers, Firecracker and newer hardened runtimes like Edera’s bring the same principle to Kubernetes. The lesson is clear: We don’t have to choose between speed and security anymore.
To see why namespaces don’t equate to isolation, we need to dive into the Linux kernel itself.
None of these mechanisms prevent one compromised container from attacking the kernel or leveraging vulnerabilities to affect other tenants. At best, they limit visibility and resource usage. They don’t provide the cryptographic or hardware-backed guarantees that modern workloads require.
Contrast that with hypervisor-level isolation:
This is the difference between partitioning and protection.
Consider CVE-2025-23266, a three-line NVIDIA container escape that allowed attackers to achieve host-level compromise. The exploit worked because privileged hooks executed inside a shared kernel context. A malicious container could inject a library via LD_PRELOAD and escape instantly.
With namespaces alone, this attack succeeded. With hypervisor-level isolation, it would have been contained. The malicious library would never touch the host kernel — it would only affect the isolated guest. This single example highlights why namespaces can’t be the last line of defense.
This is where hardened runtimes come in. A hardened runtime flips the model by:
The result is that entire categories of attacks — privilege escalation, lateral movement, kernel escapes — are structurally impossible, not just harder to detect.
AI has made solving this problem more urgent. AI agents don’t just analyze data, they execute code, hold credentials and interact with internal systems. GPUs, meanwhile, are shared across multiple tenants and workloads, often with exposed drivers and memory interfaces. Side-channel leakage is not theoretical here; it’s already been demonstrated in practice.
When namespaces are the only control, AI workloads remain vulnerable to the same class of escapes and escalations that have plagued traditional container environments. A hardened runtime with true isolation boundaries is the only way to protect against these risks at scale.
So where does this leave us? Namespaces are essential: They organize clusters, enforce policies and keep multiteam operations manageable. But they should not be confused with isolation. If Kubernetes is the contract between developers, infrastructure engineers and security teams, then namespaces are the administrative clauses. True isolation, however, is enforced in the runtime.
As an industry, we need to stop conflating these two. Logical separation is not the same as runtime protection. The former reduces clutter; the latter prevents breaches.
The good news is, we don’t need to abandon Kubernetes or containers to get there. Lightweight virtualization, hardened runtimes and hypervisor-backed containers already exist, and they integrate seamlessly with Kubernetes APIs. The technology is here. What’s needed is clarity and the will to shift the way we think about isolation.
To build secure, resilient infrastructure, we need to reset the conversation. Namespaces are valuable, but they don’t isolate. True isolation requires architectural boundaries that operate at runtime, not just at the control plane.
The next time someone says namespaces provide isolation, remember this: Partitioning is not protection. If your workloads matter — if compliance, multitenancy or AI safety are on the line — then namespaces alone aren’t enough.
The industry must move beyond the illusion of isolation and embrace runtime environments that enforce it for real.
A: Namespaces provide logical separation, not runtime isolation. Containers still share the same kernel, exposing them to cross-workload risks.
A: Hardened runtimes isolate each workload with its own kernel, preventing privilege escalation, GPU memory leaks, and container escapes.
A: Partitioning limits visibility and access; isolation enforces runtime boundaries that make cross-workload attacks impossible.
A version of this blog was previously published on The New Stack on October 21, 2025
