Comment by ashishb
1 month ago
> This is a well understood and well documented subject. Do your own research.
Anything including GNU/Linux kernel can be broken with such security vulnerabilities.
This is not a weakness in the design of containers. `npm install`, on the other hand, is broken by design (due to post-install.
> This is not a weakness in the design of containers.
Partially correct.
Many container escapes are also because the security of the underlying host, container runtime, or container itself was poorly or inconsistently implemented. This creates gaps that allow escapes from the container. There is a much larger potential for mistakes, creating a much larger attack surface. This is in addition to kernel vulnerabilities.
While you can implement effective hardening across all the layers, the potential for misconfiguration is still there, therefore there is still a large attack surface.
While a virtual host can be escaped from, the attack surface is much smaller, leaving less room for potential escapes.
This is why containers are considered riskier for a sandbox than a virtual host. Which one you use, and why, really should depend on your use case and threat model.
Sad to say it, a disappointing amount of people don't put much hardening into their container environments, including production k8s clusters. So it's much easier to say that a virtual host is better for sandboxing than containers, because many people are less likely to get it wrong.
> Many container escapes are also because the security of the underlying host, container runtime, or container itself was poorly or inconsistently implemented.
Sure, so running `npm install` inside the container is no worse than `npm install` on my machine. And in most cases, it is much better.
Containers are more isolation than without. That was never in debate in our conversation.