# Multi-Tenant Isolation

Your tenants shouldn't have to trust each other. Now they don't.

Run more customers on less infrastructure without betting your security on it.

[See How It Works](https://edera.link/demo)

Kubernetes namespaces are an organizational boundary, not a security one. Every container shares the same Linux kernel — and that kernel is the attack surface. A container escape gives an attacker a path from one tenant to every other on the node. A kernel panic takes them all down.

Most teams choose cluster-per-tenant. That means doubling your control planes, your patching cycles, your monitoring stacks, and your cloud bill every time you win a new enterprise deal. Your engineers end up managing Kubernetes and cloud sprawl. Your CFO ends up questioning your margins.

Edera is a Type-1 hypervisor that gives each Kubernetes pod its own isolated Linux kernel. We call these zones. When a workload panics, that zone goes down — nothing else does. When a container tries to escape, it hits a hypervisor boundary with no host on the other side. The blast radius of any failure is exactly one workload — by architecture, not by policy.  Each workload gets a cryptographic identity via SPIFFE/SPIRE, and true private networking ensures packets never touch the host.

60%

Node Reduction

Cut cluster sprawl, cut cloud spend

<1%

CPU Overhead

VM-level isolation at bare-metal speed

ZERO

Critical findings

Found in Trail of Bits 4-week public audit

7

CVEs Blocked

Eliminated by design, not patching

766ms

Zone startup

2.5x faster than Kata, no VT-x needed

## Go Deeper on Multi-Tenant Isolation

How container isolation works in Kubernetes, why shared-kernel boundaries fail in multi-tenant environments, and what structural isolation actually requires.

## Multi-Tenant Isolation Questions, Answered

Common questions about container isolation in Kubernetes — how Edera compares to namespaces, [Kata Containers](/content/edera-vs-kata/index.html), and [gVisor](/content/edera-vs-gvisor/index.html), and what changes when every pod runs in its own kernel.

1. **Does Edera reduce Kubernetes infrastructure costs?**  
   One Edera customer was able to reduce their infrastructure sprawl by 62% using Edera’s secure multi-tenancy, going from 40,000 servers to 15,200 servers.
2. **How does Edera handle a kernel panic?**  
   One tenant crashes. Everyone else keeps running. That's it. That's the entire answer.
3. **How does Edera differ from namespaces?**  
   [Namespaces set organizational boundaries](/content/stories/when-virtual-doesnt-mean-secure-the-false-promise-of-namespace-based-isolation/index.html) above the kernel, but they can't stop kernel-level exploits. [Edera isolates at the hypervisor](/content/stories/beyond-namespaces-real-isolation-for-kubernetes-security/index.html), each pod runs in its own zone with a dedicated Linux kernel, no shared attack surface.
4. **How does Edera compare to Kata Containers?**  
   Both use per-pod kernel isolation. [Kata requires](/content/edera-vs-kata/index.html) hardware virtualization extensions, limiting compatible instance types. [Zone startup: Edera 766ms vs. Kata 1,934ms](/content/stories/security-without-sacrifice-edera-performance-benchmarking/index.html). Edera runs on commodity hardware with no nested virtualization required.
5. **How does Edera compare to gVisor?**  
   [gVisor](/content/edera-vs-gvisor/index.html) intercepts syscalls but keeps the host kernel in the trust boundary and supports only 78% of Linux syscalls. Edera removes the host kernel entirely — every syscall runs in the pod's own kernel. No compatibility gaps, no shared attack surface.
6. **What does Edera save on infrastructure?**  
   Cluster-per-tenant multiplies control planes, patching surfaces, and [cloud spend](/content/stories/kubernetes-dirty-secret-why-youre-burning-cash-on-containers/index.html). Customers moving to [Edera's secure multi-tenant architecture](/content/stories/have-your-cake-and-eat-it-strong-isolation-while-reducing-cloud-spend/index.html) report up to 60% worker node reduction — without trading away isolation.
7. **What changes does Edera require to deploy?**  
   Two lines in the pod spec: a runtimeClassName and a kernel annotation. Existing images run unmodified — no CI/CD changes, no image rebuilds, no specialized hardware. Works with [EKS, GCP, AKS, on-prem, and bare metal](/content/stories/product-update-now-on-azure-linux-plus-bare-metal-ai-performance-and-deeper-security/index.html). No change management, no retraining your team, no renegotiating your cloud contract.
8. **What is Edera's trusted computing base?**  
   Standard containers trust the entire Linux kernel — 30M+ lines of code — as their security boundary. [Edera's TCB is the Xen microkernel](/content/stories/edera-reduces-the-hypervisor-attack-surface-with-rust-and-xen/index.html), written in MISRA C with Rust services. Trail of Bits found zero high or medium severity findings.
9. **How can I learn more about the Trail of Bits public audit of Edera?**  
   The report on the Trail of Bits penetration test is available in Edera's [Trust Center](https://trust.edera.dev/). You can also read more about the process in [our blog post on the audit](/content/stories/security-built-into-our-dna-how-edera-achieves-enterprise-grade-protection/index.html). In their executive summary, Trail of Bits concluded: "The security posture of Edera and its surrounding infrastructure is generally robust, with no medium or high severity findings identified in this audit."

## The Multi-Tenancy Gloss

Key terms for understanding container isolation, kernel boundaries, and secure multi-tenancy in Kubernetes — from blast radius and container escapes to how RuntimeClass and hard multi-tenancy actually work.

- **Blast Radius**  
   The scope of impact from a failure or breach. A kernel panic in standard Kubernetes affects every container on the node. In Edera, the blast radius is one [zone](/content/stories/what-the-f-ck-is-a-zone-secure-container-isolation-with-edera/index.html) — one workload.
- **Container escape**  
   An attack exploiting a kernel bug to break out of a container and reach the host. Examples: Dirty Pipe, [Leaky Vessels](https://docs.edera.dev/guides/pov-validation/), CVE-2025-23266, cr8escape. Edera eliminates this class — no shared kernel to escape to.
- **Kubernetes RuntimeClass**  
   A Kubernetes field that selects the container runtime for a pod. Adding `runtimeClassName: edera` to a pod spec is [all that's required](https://docs.edera.dev/getting-started/) to run it in an isolated Edera zone.
- **Lateral Movement**  
   When an attacker pivots from a compromised container to other workloads or the host. Possible on [shared-kernel Kubernetes](/content/stories/the-shared-kernel-is-the-real-problem-in-container-security/index.html). Architecturally prevented in Edera — zones share no kernel to traverse.
- **Multi-Tenancy**  
   Soft multi-tenancy uses namespaces — logical separation, shared kernel. [Hard multi-tenancy](/content/stories/what-the-f-ck-is-multitenancy-secure-efficient-containers-explained/index.html) uses hardware isolation with separate kernels per workload. Edera delivers hard multi-tenancy at container density.
- **Noisy neighbor**  
   When one tenant's workload degrades or crashes others sharing the same node. On shared-kernel Kubernetes, this can escalate to node-wide panics. Edera [contains failures to a single zone](/content/stories/beyond-namespaces-real-isolation-for-kubernetes-security/index.html).
- **Shared Kernel**  
   Every container on a node shares one Linux kernel. Any kernel vulnerability is exploitable from any container on that node. Edera removes this by giving [each pod its own kernel](https://docs.edera.dev/technical-overview/architecture/overview/).
- **Trusted Computing Base (TCB)**  
   All hardware and software components critical to system security. Smaller TCB means less to trust and audit. [Edera's TCB: Xen microkernel](/content/stories/edera-reduces-the-hypervisor-attack-surface-with-rust-and-xen/index.html). Containers trust the entire Linux kernel (30M+ lines of code).
- **Type-1 hypervisor**  
   A hypervisor running directly on hardware, beneath the OS, with no host OS in the trust boundary. Edera's is [based on Xen](/content/stories/edera-reduces-the-hypervisor-attack-surface-with-rust-and-xen/index.html), written in MISRA C. A Type-1 hypervisor provides stronger isolation than Type-2 (hosted) hypervisors.
- **Zone**  
   An [isolated environment](/content/stories/what-the-f-ck-is-a-zone-secure-container-isolation-with-edera/index.html) giving each Kubernetes pod its own Linux kernel, backed by a hypervisor-managed VM. Kernel failures and escapes cannot cross zone boundaries.