Layers of Isolation in Kubernetes
summary
Explains concrete isolation guarantees: containers use cgroups, namespaces, seccomp and AppArmor/SELinux but remain vulnerable to kernel resource exhaustion (demonstrated with a fork‑bomb) unless pod PID limit (alpha in 1.10) is set; pods gain network namespaces so network policy can block lateral scans that enumerate the kubelet read‑only port; nodes hold kubelet credentials and can read mounted secrets but are limited by node authorizer and node restriction (since 1.7); gVisor and Kata containers add VM‑like sandboxes at the pod level.
AI-written summary · about
chapters (22)
- 0:00Start
- 1:16Key Properties of Isolation
- 3:33How Much Isolation Is There between Two Containers Running in the Same Pod
- 4:08What Are some of those Features That Enable Container Isolation in Kubernetes
- 4:37Kernel Resources Are Isolated
- 6:54Kernel Resource Exhaustion
- 9:07Pods
- 9:30Name Network Isolation
- 11:28Example of Why Network Policy Is Valuable
- 13:50Kubernetes Dashboard
- 14:43Kubernetes Namespaces
- 17:44Nodes
- 18:17How Much Isolation Is There between Different Nodes on the Cluster and the Control Plane
- 19:01Hardware Level Resource Isolation
- 21:51Node Authorizer and Node Restriction Plugins
- 22:28Sandbox Isolation
- 23:28Clusters
- 23:45Cluster Isolation
- 24:00Control Plane
- 25:17The Infrastructure Layer
- 25:54Recap
- 27:03Conclusion
related talks
14mYour Containers Aren’t Alone: Demystifying Container Isolation
31mYour Containers Aren’t Alone: Demystifying Container Isolation
47mContainer Security
25mUnderstanding Isolation Levels in the Kubernetes Landscape
35mKubernetes Security - Challenge and Opportunity?
42mImproving Containers Isolation in Kubernetes
19mSandbox to confidential containers: A brief on the evolution of container isolation
24mSecure Pods