Module 4 of 5
Isolation
What actually separates one workload from another, from kernel namespaces to microVMs to the network, and why most isolation boundaries are configuration that defaults to open.
A running workload shares a machine, a kernel, an orchestrator, and a network with many others. Isolation is the set of boundaries that decides what an attacker who lands inside one workload can reach: the next process, the host, the cluster’s control plane, the database three hops away. Almost none of these boundaries are on by default, and most are configuration rather than hardware, so the gap between “isolated” and “shares everything” is usually a few settings.
This module works outward from the narrowest boundary to the widest. It starts with what a container actually is at the kernel level and why it is not a security boundary by default, moves up to the Kubernetes security model and the grants that quietly confer cluster-admin, then to stronger sandboxes and microVMs for untrusted code, and finally to network segmentation and zero trust so that a single compromise reaches as little as possible. By the end you should be able to look at a workload and say what its blast radius is, and which setting would shrink it.
Lessons
- 4.aContainers from the kernel upWhat actually isolates a container, and why is it not a security boundary by default?15 min
- 4.bThe Kubernetes security modelHow does Kubernetes decide who may do what, and which grants quietly mean cluster-admin?15 min
- 4.cSandboxes and microVMsWhen is a container not enough, and how do you choose a stronger sandbox?15 min
- 4.dNetwork segmentation and zero trustWhy does a flat network amplify a breach, and how do segmentation and zero trust contain it?14 min