As an example of the difference directly related to k8s "Security settings that you specify for a Container apply only to the individual Container, and they ov

As an example of the difference directly related to k8s "Security settings that you specify for a Container apply only to the individual Container, and they override settings made at the Pod level when there is overlap." https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ https://kubernetes.io/docs/tasks/configure-pod-container/sec... While there are other Byzantine faults like this CSV, that should give you a hint. The problem is that containers depend on good actors dropping privlages on a shared kernel. Where VM's have a natural abstraction and their own kernel, containers require proper configuration of seccomp, apparmor, selinux, dropping privileges, etc... to reduce the attack surface. An easy demonstration of this is to launch a privlaged container and run insmod with some random kernel module on the host OS. In namespaces, you start with no isolation, and you add whatever you want or more realistically remember to add. They are not jails where you start with a reasonable secure baseline. In fact the k8s 'baseline' pod security standard still has MKNOD caps which can result in issues like CVE-2021-25741. While /proc now has filtering /sys doesn't and you can find the major minor numbers of the hosts root filesystem and read it from a container. It is not that containers can't be made reasonably secure, but that they aren't inherently secure. They are default allow all because they are inherently just namespaces implemented basically through value remapping.