I'm confused why the author keeps associating containers with total insecurity. Docker's approach to whitelisting access to the filesystem has been great in my

I'm confused why the author keeps associating containers with total insecurity. Docker's approach to whitelisting access to the filesystem has been great in my experience. I've managed classic multi-tenant Linux servers before, and I've pretty much always found lots of examples of services having read or even write access to each other's files unnecessarily. Docker's strong whitelisting-based approach to filesystem access seems so much more ideal. In the video of someone breaking into a Kubernetes cluster, they start off with restricted kubectl access. Okay, so restricted kubectl access isn't a strong security boundary. I don't think it's a big deal to a lot of people's use-cases. I didn't know it was a feature; the lack of a strong feature like that is only a dealbreaker to certain kinds of setups. It doesn't seem necessary for sandboxing different services apart from each other; it's for giving different sysadmins/developers access to deploying to different parts of the cluster. I'm going to make a wild guess that the issue isn't core to and unfixable in Kubernetes, because the person in the video shows a way to plug the issue. Summarizing this as calling Kubernetes security a clusterfuck is way over the top. I could believe that the author's NanoVM project is even better at security out of the box, but I find the way they present the argument as overblown, and they don't introduce NanoVM for comparison until the end, so I think the arguments are doubly misleading because most people are going to be comparing containers to the classic plain multi-tenant Linux server model, and Docker and Kubernetes seem like at least an improvement to that in security.