A Commencement into Real Kubernetes Security

The speakers argue that many Kubernetes teams spend their effort on the wrong risks. Container breakouts, custom seccomp profiles and runtime security tools get most of the attention, yet they are costly to run well and are rarely what attackers use. They show that a seccomp profile built from a simple application's system call trace grew from 17 calls to nearly 1,900 once the app was packaged into a container, and that the resulting profile quietly allowed risky calls such as clone and BPF. Their point is that custom sandboxing is hard to get right and is mainly worth the effort for services that run untrusted customer code.

The main part of the talk is a live penetration test against a cluster that was hardened to the CIS benchmark, with no failing checks and no CVE findings. Starting from a notebook pod, the speakers found a service account token in another container's working directory because the pods shared a process namespace. That account could patch pods, which let them swap in their own image. A helper binary run on a node then harvested tokens and certificates from the host, and one account could create mutating admission webhooks. That allowed a sidecar to be injected into every new pod. They note that real criminals in this position are more likely to deploy cryptomining than to steal data, and a graph-based attack path tool confirmed the full route.

The takeaway is to focus first on role-based access control, on who can create pods or read secrets, and on admission control that blocks privileged pods and host namespaces. Counting CVEs in images matters less when the vulnerable code is never reached, and benchmark scores can create false comfort because many checks are manual. Teams should know their own threats and make the case for the right priorities to management and compliance.