Security and Kubernetes: Should We Go Back to VMs?
summary
Discusses risks from Docker sharing a host process and Kubernetes’ default in-cluster security trade-offs, and presents concrete mitigations: mTLS for pod-to-pod encryption, NetworkPolicy for intra-cluster firewalling, image signing/provenance checks, and notes PodSecurityPolicy deprecation in 1.21. Describes operational burdens like urgent per-image patching after the 2019 Alpine issue and demos alternatives that restore VM-level isolation with near-container startup times, specifically Kata Containers and Firecracker micro‑VMs.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 0:45Security and VM history
- 2:52Containers and orchestrators
- 3:57Kubernetes network security
- 4:59App security and delegation
- 6:22Kubernetes Network Policies
- 7:45Deprecated Pod Security Policies
- 8:47Image security and deployments
- 10:09Minimal privileges and Linux
- 11:54Micro-VMs and stronger isolation
- 13:18Alternatives to containers
- 14:21Conclusion and security choices
related talks
47mContainer Security
28mKubernetes Security Low-Hanging Fruit
35mKubernetes Security - Challenge and Opportunity?
46mContinuous Kubernetes Security
53mFlying Above the Clouds: Securing Kubernetes
19mHow to Secure Your Kubernetes Clusters
43mKubernetes Security: Attacking and Defending Modern Infrastructure
32mLotsa security - confining the extra security layer