Containers are absolutely a security boundary, and an excellent one at that - at least, Docker containers are. 1. You get file, process, and network namespaces

Containers are absolutely a security boundary, and an excellent one at that - at least, Docker containers are. 1. You get file, process, and network namespaces, which are a security boundary 2. You get a seccomp filter, which is a security boundary The "containers are not a security boundary" meme needs to die. Elsewhere you mention that "containers are not sufficient for untrusted code" but that's a very specific and very niche threat model. Most people don't say "send me a binary and I'll execute it", or have arbitrary RCE + multitenancy concerns. Containers aren't sufficient for multi-tenant RCE because the RCE is by design so 100% of your security pressure is on the container at that point. In the vast majority of cases you're dealing with servers that don't intend to allow arbitrary code execution, and containers are an extremely easy way to drive up the cost of an attack given that the attacker has already spent a lot of time and money on the RCE. SELinux is also not sufficient for the "RCE by design" threat model - is SELinux not a security boundary? Further, containers can limit the impact of remote vulnerabilities like path traversal attacks, since they have file isolation by default. edit: I see elsewhere that there's a real lack of clarity here. First off, a security boundary can be meaningfully defined as a limitation on an attacker that does not have a way around it without additional exploitation. So the main reason why people have said "containers are not a security boundary" is because: a) Very, very early on, escaping a container was trivial - like you could just ask to leave and you'd be out. b) There were some blog posts basically saying "containers aren't sufficient for multi-tenancy" where arbitrary users can run arbitrary code on the same host. This is still the case today - but it's also an extremely rare threat model. Why would containers not be sufficient for (b) ? Because the majority of the Linux kernel is still exposed to the attacker within a container - the vast majority of system call interfaces are exposed (but seccomp removes a number of these, which is nice). The Linux kernel is not at all sufficiently hardened against attackers who can make arbitrary system calls, therefor containers are not sufficient against those attackers. If you give the attacker RCE by default (ie: your service is "Send me a binary and i'll run it") then an attacker can spend all of their time and money just on a local privesc, which isn't crazy difficult. Since the cost of RCE in an RCE-aaS is 0 the consensus is that containers aren't strong enough for RCE-aaS threat models. In that case use Firecracker or gVisor or a dedicated host. Otherwise, RCE costs tend to be pretty high and having to develop an additional LPE on top of one is, at minimum, quite a pain for many attackers. Containers are extremely easy to deploy software into, something like a Firecracker VM is not. Containers are basically just processes, so you can monitor them and manage them trivially. Monitoring and managing VMs with processes inside of them is obviously harder. So I think the 'bang for your buck' with containers is extremely solid.