"two approaches but run data pipelines in a fully isolated environment - containers - which prevents user code from breaking free."<p>While (user) namespaces, root-less and cgroups do slightly reduce the attack surface, they are still running on a shared kernel instance.<p>In Dockers default configuration, using host namespaces and allowing --privlaged, anyone who can launch a container has full root level access to read disks of even the host machine via mknod or even update firmware. Lets hope that they are not using Linux bridges for containers too.<p>The belief that containers are somehow ultra secure will result in many breaches in the future. In theory if you have control of the code SELinux or Apparmor could help but most people don't use them and a major cloud providers solution doesn't even support them.<p>It is scary how many install bases even add capabilities to the container daemons so that they can run some form of storage persistence etc...<p>The risk of containers can be mitigated to an acceptable layer. But when ever I hear a company claiming that they are using containers because they are "secure" it is a huge red flag.<p>If you are a company making claims like the above, you are proclaiming that you either think that security through obscurity is a primary cybersecurity practice or you really don't understand how containers and namespaces work.