Container Isolation and the “VMs vs. Containers” Debate
The podcast mainly focuses on container isolation, a topic we’re fiercely passionate about at Edera. It begins with the age-old question:
“What is more secure? VMs or containers?” Michele opines, “That's the wrong question.”
Comparing virtual machines and containers isn’t helpful beyond a thought exercise because much of the world has shifted their workloads to containers due to the convenience of orchestration platforms like Kubernetes and the developer experience of Docker.
But what if we could integrate the best security features of virtual machines, such as isolation and improved resource management, into the world of containers? Containers infamously don’t contain and lack isolation from a shared kernel state. Michele rightly points out that container isolation isn’t really a thing.
Segregating Workloads: The Cost of Containers that Don’t Contain
“I never say isolation with containers; I say segregation because it’s a shared kernel.“
We’ve encountered countless organizations segregating their containerized workloads from others with expensive, dedicated, and segregated cloud environments. Running redundant infrastructure because containers don’t contain increases costs, complexity, and technical debt. But segregating workloads is better than the alternative of deploying and losing sleep over one rogue container stomping on a multi-tenant environment and stealing other customers' or teams' data.
Losing sleep over the fact that containers don’t provide isolation and hoping for the best inspired Edera’s loving axolotl “F&$k luck” logo. At Edera, we live by the “hope is not a strategy” mindset of site reliability engineering (SRE).
Container Escapes vs. VM Escapes: Examining Isolation Risks
The podcast also compares the differences in container and virtual machine isolation. Container escapes are much more of a common threat than VM escapes due to the way containers are architected and due to the fact they share a host kernel. VM isolation on the other hand, has enabled cloud providers like AWS to isolate untrusted VMs from their control plane and other customer infrastructure safely. Fun fact: AWS was built on Xen, the type 1 hypervisor of choice for Edera.
A modicum of analysis shows at least five container escapes in 2022 due to vulnerabilities alone, not to mention container escapes from the myriad of ways application developers and Kubernetes operators can provide ambient permissions to workloads. Virtual machine escapes do happen, but they’re far less frequent. Google has a $250k bounty for vulnerabilities in the KVM hypervisor, and Zerodium lists up to $200k for a VMware vulnerability.
Trust Boundaries and Kubernetes: Why Namespaces Aren’t Enough
“You have to be more careful about trust boundaries on your Kubernetes clusters.”
Unfortunately, the standard for trust boundaries in Kubernetes is namespaces. Namespaces are a logical grouping of resources and were never intended to provide boundaries for applications or tenants in Kubernetes. Trust boundaries are difficult to achieve in Kubernetes because the primitives are complex and deviate from the default.
In Edera, our hypervisor instantiates containers inside of “zones”, which are isolated virtual machine environments. With Edera zones, we can create trust boundaries at nearly any granularity, from a zone-per-container, pod, deployment, or namespace. By default, every pod resides in its own trust boundary, isolated from the host and from other containers, but we understand that our users might need more flexibility so they get to define their own trust boundaries.
Unseen Risks: The Overlooked System Containers of Kubernetes
“There is usually a lot of focus on application containers, and I never hear people talk about system containers. The containers that make up Kubernetes itself.”
We agree that infrastructure components are often ignored (and far too often, overly privileged!). To mitigate this risk, our secure-by-design approach runs Kubernetes system components like the api-server, etcd, and the kubelet in an untrusted virtual machine “zone” in Edera, isolating critical infrastructure workloads from application containers.
Edera is changing the paradigm for container security, allowing you to define and deploy real trust boundaries with strong isolation between your containerized workloads. This unlocks native multi-tenancy security without needing to segregate your containerized workloads. Don’t just take it from us. Kubernetes co-founder Joe Beda said Edera “allows Kubernetes to go places it has never gone before.” If you’d like to know how to secure your containers, reach out to us.
