Detect and Respond? Cool Story — or Just Don’t Let the Bad Stuff Start.

The talk argues that Kubernetes workloads should be hardened before they run, rather than relying mainly on detection and response afterwards. The presenter uses an analogy about a building where guards, locked doors and access rules prevent problems up front, with cameras serving as a backup. The default Kubernetes setup offers little protection: container images often run as root with package managers installed, and pods and deployments run whatever the container asks for.

To make this concrete, the presenter follows a small Python app with a deliberately planted command-execution flaw. A single request gives an attacker a root shell inside the container, from which they can install scanning tools, read sensitive files and reach the mounted service account token. Kyverno is then introduced as an admission controller that validates deployments before they enter the cluster. A policy in enforce mode rejects pods that do not set a non-root security context, and it returns a readable message to the developer. The presenter notes that mutating the manifest instead can leave the container unable to start.

Next, KubeArmor restricts behaviour at execution time using Linux security modules. Its policies block writes to /tmp, block running the Python binary that would be used for listeners, and block shell access, while the legitimate Flask app keeps working. The presenter acknowledges limits: some workloads genuinely need root, and some normal activity can look suspicious. Runtime observability with eBPF is suggested as a way to watch what gets through. The main takeaway is to validate configuration at admission, restrict what containers can execute, and keep monitoring as a backstop. Node and cluster hardening were left out of scope.