Container security has a problem: the main focus to address its shortcomings is to rely on sandboxes. Sandboxes work by limiting access to dangerous resources to protect the system from misconfigurations or malicious code. Architecturally, container sandboxes denylist access to resources or introduce additional layers to protect the shared Linux kernel from a rogue container. Sounds good but it’s extremely fragile. One false configuration in a sandbox can negate all the protections. 

In short, even the most sophisticated sandboxes are simply bandaids aimed at restricting access to the most vulnerable resource on a system: the shared kernel.

Container sandboxes “contain” workloads by bolting on controls at the Linux kernel level:

  • Seccomp to filter system calls
  • AppArmor or SELinux to restrict access
  • Linux capabilities to trim permissions

Each of these requires authoring security configurations that require perfectly predicting attacker behavior ahead of time and are therefore fragile to breaking or being ineffective. Miss one syscall, or misconfigure one profile, and you’re staring down a container escape. Name a sandbox that hasn’t had multiple jailbreaks.

What Is a Hardened Runtime and How It Solves Container Security

Instead of trying to limit what workloads can reach in the shared kernel, a hardened runtime changes the paradigm:

  • No shared kernel. Workloads don’t get to touch host resources at all.
  • No need for perfection or stacked controls. If the kernel isn’t shared, you don’t need to rely on predicting your adversaries behaviors perfectly with bespoken seccomp filters, AppArmor rules, or capabilities gymnastics.
  • Isolation by design. The workload runs in its own isolated environment, enforced at a hypervisor level with minimal attack surface.

Think of it this way: sandboxing is like letting someone into your house and then locking every room they’re not supposed to enter and leaving a lockpick on the coffee table. 

Why Hypervisor Isolation Outperforms Sandboxing in Container Security

  1. Architectural Security: Sandboxes rely on denylisting. Denylists require unrealistic vigilance, explicitly defending every possible attack path. Hardened runtimes eliminate entire classes of risks by never exposing resources in the first place. No shared file descriptors, inodes, syscalls, or shared kernel to worry about.
  2. Performance Without Penalty: Every sandbox layer adds performance overhead – syscall filters, kernel mediation, namespace juggling. Hardened runtimes cut through that by removing the shared kernel altogether. With a Type-1 hypervisor under the hood, workloads get VM-grade separation, behaving like containers for developers, with hyperscale cloud performance.
  3. Future-Proof by Design: AI and GPU workloads push infrastructure harder than ever. Sharing GPUs or exposing device drivers across sandboxes invites existential risk. Hardened runtime isolates these paths at the lowest layers by default, making side-channel attacks and driver exploits structurally impossible. (See Edera in action here)

Most notably, Hardened Runtimes provide strong isolation and remove entire classes of attacks by default. No configuration and policy authoring for each component is necessary.

Sandboxes vs. Hardened Runtime (At a Glance)

Tl;dr: Sandboxes limit what workloads can do. Hardened runtime redefines what workloads are allowed to touch — removing the shared-kernel risk entirely.

Sandboxes Share the host kernel — workloads still touch the same underlying system. Restrict workloads using seccomp, AppArmor, and Linux capabilities. Require complex, error-prone configuration to predict every possible attack path. Are fragile — one missed syscall or misconfigured profile can lead to container escape. Add performance overhead due to syscall filtering, namespace juggling, and policy enforcement. Work — until they don’t. Security depends on constant maintenance and perfect configuration. Hardened Runtime No shared kernel — workloads run in fully isolated environments enforced by a Type-1 hypervisor. No kernel policy gymnastics — no need for layered seccomp, AppArmor, or capability tuning. Isolation by design — each workload is confined at the hardware virtualization layer. Near-native performance — removes sandbox overhead for faster startup and throughput. Secure by default — eliminates entire classes of attacks without relying on human-authored denylists. Future-proof — built for modern AI, GPU, and multi-tenant workloads where shared kernels fail.

The Future of Container Security: Hardened Runtime by Edera

Sandboxes were a patchwork solution for an earlier era of container security. They’re brittle, slow, and prone to jailbreaks.

A hardened runtime flips the model. Instead of containing untrusted workloads with increasingly byzantine rules, it removes the attack surface altogether.

That’s why we built Edera this way: a hardened container runtime that delivers isolation, performance, and future-proof security — without tradeoffs.

“WTF is...?” series

‍