Container Security
summary
Containers share the host kernel so isolation sits between bare metal and VMs: claim backed by examples — only two KVM breakouts in ten years, but common kernel bugs (Spectre/Meltdown) can compromise all containers. Practical controls discussed: mount kernel filesystems read-only, drop capabilities, device cgroups, seccomp to cut syscall surface, and SELinux + MCS to keep container filesystems separate. User namespaces now work in podman with overlayfs fixes; KATA (KVM-based), gVisor and other runtimes exist but add tradeoffs for volumes and performance.
AI-written summary · about
chapters (13)
- 0:00Start
- 5:10Run Multiple Services on the Same Machine at the Same Time
- 17:22Protect the Kernel Filesystems
- 19:07Linux Capabilities
- 21:24Captious Admin
- 23:29Control Access to Device Nodes
- 28:01Type Enforcement
- 28:50Container Breakouts
- 33:07Protect the Syscall Table
- 35:08Block 32-Bit Sis Calls
- 36:43Discretionary Access Control
- 37:19User Name Space
- 41:08Oci Runtimes
related talks
14mYour Containers Aren’t Alone: Demystifying Container Isolation
31mYour Containers Aren’t Alone: Demystifying Container Isolation
32mLotsa security - confining the extra security layer
33mContainers Security Layers and How Not to Break them
29mLayers of Isolation in Kubernetes
25mYou Can’t Handle the Root! Container Isolation...
16mSecurity and Kubernetes: Should We Go Back to VMs?
14mA kernel? In a Container? Explain Yourself!