Containers Don't Contain: Watch Our Session on MicroVMs and the Hugging Face Breach

On July 23, Edera CTO Alex Zenla and Head of Security Jed Salazar spent an hour on the question: what do people actually mean when they say "container isolation"? The Hugging Face/OpenAI breach has put a new focus on the impact AI is having on exposure and risk that comes with the Linux kernel, and the importance of isolation in this new age.

Watch the recording.

The timing was accidental. OpenAI had published its breakdown the day before, confirming that one of its own models broke out of its own sandbox before it ever touched Hugging Face. The model was being scored on an evaluation called Exploit Gym. It worked out that the answer key lived in Hugging Face's production environment and treated getting there as the shortest path to a better score. Nobody instructed it to attack anyone.

Read more

Kicking it off with OpenAI/Hugging Face Coverage

Jed and Alex kick off the event with a discussion around what happened and why they believe this isn’t the exception, and may soon become the rule.

The discussion included:

• Why the code-execution bug is the least interesting part of the incident, and what Alex thinks would have prevented it upstream
• Jed on why this looked less like an AI exploit and more like a nation-state long-tail operation—plus the sentence that reframes the whole risk model: finding a kernel bug for a container escape used to take a rare skill set, and now it's an API call
• What a container actually is once you take it apart, and why cgroups provide no security whatsoever
• The production bug that taught Alex the hard way that cgroups don't account for what you think they account for
• Why enabling user namespaces can increase your attack surface

And the line we'll be stealing for the rest of the year: multi-tenancy via namespaces and cgroups is multi-tenancy by politeness.

Why It’s Worth the Hour

Then the presentation really gets going and they talk about real isolation opportunities. Alex outlines what's harder with microVMs – memory overhead, cold starts, GPU pass-through, and the fact that eBPF often just doesn't work. She even covers the biggest trade-off of running Edera.

If you're evaluating secure execution platforms, that stretch is worth more than the slides in front of it.

Related Reads

• "CYA: Contain Your Architecture"—both escalation chains from the breach, step by step
• "Dirty Frag"—one of the kernel CVEs Alex cites, in depth 
• "Kata vs. Firecracker vs. gVisor: Isolation Compared"—the landscape slide, written out 

Frequently Asked Questions

Is a container a security boundary?

No. A container is a UX abstraction—the kernel has no concept of one. It's a bundle of namespaces and cgroups, and both assume the process inside isn't hostile.

What's the difference between a container and a microVM?

A container shares the host kernel with every other workload on the node. A microVM gets its own kernel, with a hypervisor enforcing separation. One kernel bug compromises every tenant in the first model and one workload in the second.

Do microVMs slow workloads down?

Not meaningfully. Edera runs within a few percentage points of the host and sometimes faster. Alex covers where the real costs show up instead.

Or skip ahead and try it: EderaON is our free single-node access program – drop Edera onto an existing cluster in under an hour. Want to talk through your own architecture first? Grab time.