Why Containers Alone Aren’t Secure

When deploying an application in the cloud, you likely package it up as a container, then deploy this container in a cloud environment. It may be the only container running on the machine, or may be sharing resources with other containers. But just because the application is inside a container, it doesn’t mean that it’s isolated.

Things like Linux namespaces and cgroups make it look like these containers are running on their own, but really they have a shared kernel and address space. This means a container may be able to view data or affect the performance of other containers running on the same infrastructure. This can take the form of a container escape or noisy neighbor attack. 

These attacks show that containers alone aren’t an isolation boundary. So what we need is someplace to put our containers that does provide this isolation. This is where Edera Zones, our production grade sandboxes, come into play. They provide the missing isolation boundary for containers, providing a hardened runtime without the need for expensive bare metal instances or performance penalties.

What Is a Zone?

Edera provides a container-native hypervisor that provides strong isolation without sacrificing performance or usability. We do this by running the containers you already have in zones, a concept borrowed from Solaris Zones and FreeBSD jail that describes an isolated environment without the need for hardware virtualization. 

Micro-VMs vs. Zones

Zones are similar to micro-VMs, but with a few important differences. Like Edera zones, micro-VMs ensure that containers running on the same system can’t interfere with each other. Micro-VMs run each container in its own virtual machine (VM) with its own kernel and address space. This provides a strong isolation barrier around the container.

However, many virtual machine technologies come with performance or usability tradeoffs. VMs that are built on KVM require bare metal instances to run in the cloud, as they require direct access to CPUs that support hardware virtualization. This need decreases availability and increases costs. Further, many VM technologies are slow to start and run containers.

How Edera Zones Solve Container Isolation

Instead of sacrificing performance or availability, Edera uses a Xen-based memory-safe hypervisor to achieve near-native container performance when running containers in zones without the need for direct hardware access.

An Edera zone is like the guest environment of a VM. Like a guest VM it has its own kernel and address space and provides strong isolation. Edera zones are packaged as OCI images for cloud native compatibility, and by default each zone runs a single pod. 

Why Zones Matter

Basically, a zone is the security boundary that your containers were missing. If you package your application as a container, just like you would normally, and run it in Edera, you can run it with peace of mind knowing it will be performant and not impacted by other containers.

To learn more about Edera zones and give your containers the isolation they need, check out our docs

FAQ

Q1: What is a zone in cloud computing?
A1: A zone is an isolated runtime environment that provides strong security boundaries for containers, preventing escapes and noisy neighbor issues.

Q2: How are Edera Zones different from micro-VMs?
A2: Zones deliver VM-like isolation but without the performance penalties or hardware requirements of traditional VMs.

Q3: Why do containers need zones?
A3: Because containers share a kernel, they aren’t a true isolation boundary. Zones provide the missing layer of security.

“WTF is...?” series