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

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.

RELATED READS

January 21, 2026

The Shared Kernel Is the Real Problem in Container Security

Read more

December 3, 2025

What is Confidential Computing? From Encrypted Execution to Zero-Trust Workloads

Read more

October 29, 2025

What Is Multitenancy? Secure & Efficient Containers Explained

Read more

7 Critical NVIDIA GPU Vulnerabilities Expose AI Systems

We’re Isolating Kubernetes

Multi-Tenant Isolation Questions, Answered

Common questions about container isolation in Kubernetes — how Edera compares to namespaces, Kata Containers, and gVisor, and what changes when every pod runs in its own kernel.

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.

One tenant crashes. Everyone else keeps running. That's it. That's the entire answer.

Namespaces set organizational boundaries above the kernel, but they can't stop kernel-level exploits. Edera isolates at the hypervisor, each pod runs in its own zone with a dedicated Linux kernel, no shared attack surface.

Both use per-pod kernel isolation. Kata requires hardware virtualization extensions, limiting compatible instance types. Zone startup: Edera 766ms vs. Kata 1,934ms. Edera runs on commodity hardware with no nested virtualization required.

gVisor 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.

Cluster-per-tenant multiplies control planes, patching surfaces, and cloud spend. Customers moving to Edera's secure multi-tenant architecture report up to 60% worker node reduction — without trading away isolation.

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. No change management, no retraining your team, no renegotiating your cloud contract.

Standard containers trust the entire Linux kernel — 30M+ lines of code — as their security boundary. Edera's TCB is the Xen microkernel, written in MISRA C with Rust services. Trail of Bits found zero high or medium severity findings.

The report on the Trail of Bits penetration test is available in Edera's Trust Center. You can also read more about the process in our blog post on the audit. 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."

Interested in general Edera FAQs?

The Mutli-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.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

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 — one workload.

An attack exploiting a kernel bug to break out of a container and reach the host. Examples: Dirty Pipe, Leaky Vessels, CVE-2025-23266, cr8escape. Edera eliminates this class — no shared kernel to escape to.

A Kubernetes field that selects the container runtime for a pod. Adding runtimeClassName: edera to a pod spec is all that's required to run it in an isolated Edera zone.

When an attacker pivots from a compromised container to other workloads or the host. Possible on shared-kernel Kubernetes. Architecturally prevented in Edera — zones share no kernel to traverse.

Soft multi-tenancy uses namespaces — logical separation, shared kernel. Hard multi-tenancy uses hardware isolation with separate kernels per workload. Edera delivers hard multi-tenancy at container density.

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.

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.

All hardware and software components critical to system security. Smaller TCB means less to trust and audit. Edera's TCB: Xen microkernel. Containers trust the entire Linux kernel (30M+ lines of code).

A hypervisor running directly on hardware, beneath the OS, with no host OS in the trust boundary. Edera's is based on Xen, written in MISRA C. A Type-1 hypervisor provides stronger isolation than Type-2 (hosted) hypervisors.

An isolated environment giving each Kubernetes pod its own Linux kernel, backed by a hypervisor-managed VM. Kernel failures and escapes cannot cross zone boundaries.

Book a Meeting

Green calendar icon with grid and two tabs on top inside a black circular background.

Ready to stop the sprawl?

See what multi-tenant isolation looks like at your scale.