Kubernetes security failures usually do not look like network intrusions. An attacker who gets code execution inside a container, through an application bug, a poisoned dependency, or a policy gap that let a privileged pod schedule, is already inside the perimeter the firewall was watching. From there the firewall verified nothing: which secrets the process can reach, which syscalls it can make, whether the running image is even the one you signed.

That is the useful reframe. Kubernetes security is not one problem at the boundary. It is three problems inside it, and each one needs its own control that keeps working when the others fail:

Admission decides what is allowed to deploy, and with what configuration.

Identity decides what each running pod is allowed to reach.

Runtime watches what a pod actually does, which is often not what its manifest claimed.

None of the individual tools below are new, and none of this is a new technique.…