"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/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.
As an example, a VM from a reputable cloud provider is secure enough for most purposes, likewise I'd trust managed containers from a reputable cloud provider (except Azure, they have a dodgy track record when it comes to container security)
In many circumstances you can make some tradeoffs, like running multiple customers or projects on the same vmware installation, because the risk is low or the other tenants are well known. I don't think Kubernetes is quite there yet where I'd trust multiple tenants on the same cluster.