Your Containers Aren’t Alone: Demystifying Container Isolation
summary
Surveys concrete isolation layers and tradeoffs: namespaces and cgroups give low‑overhead process separation but kernel CVEs let containers mount or rewrite host filesystems as seen in recent runc buildkit and Nvidia toolkit exploits; GVisor and Firecracker microVMs add a separate runtime or kernel per workload, raising startup and compatibility costs but blocking many kernel‑level escapes; node separation costs whole machines; confidential computing (TEEs, Confidential Containers) encrypts memory but requires trusted hardware and vendor support, and CPU flaws like Rowhammer still matter.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:22What are containers
- 3:08Containers in multi-tenant
- 4:56Why isolation matters
- 7:22Four isolation categories
- 9:26Application isolation with namespaces
- 12:40Runtime isolation with G Visor
- 14:03Virtual machines and microVMs
- 16:10Hypervisors KVM and Zen
- 18:17Firecracker and Cloud Hypervisor
- 19:20Kata Containers and Unikernels
- 20:46WebAssembly isolation
- 22:08Node isolation by hardware
- 23:13Confidential computing
- 24:35Isolation technologies compared
- 27:23Open source future
- 27:46Q&A
related talks
25mYou Can’t Handle the Root! Container Isolation...
47mContainer Security
29mLayers of Isolation in Kubernetes
19mSandbox to confidential containers: A brief on the evolution of container isolation
34mContainer Runtimes... on Lockdown: The Hidden Costs of Multi-tenant Workloads
45mMaking Containers Safer
27mTrust No One: Bringing Confidential Computing to Containers
33mContainers Security Layers and How Not to Break them