Whilst it's always good to see articles discussing the relative merits of various container runtimes for isolation, there seems to be a tendency to underplay the security benefits of standard Linux containerization (As used by LXC/LXD and Docker)
In the case of this article, in the Docker section there's no mention of the Apparmor/SELinux policy that gets applied to containers and no mention of the seccomp policy that's used by default to constrain some syscalls from a running container.
My general take on it is that Docker/LXC provide quite flexible security models, which can be modified to suit a user's process (e.g. by dropping unneeded capabilities from the default set or adding a custom seccomp profile)
gvisor provides a higher level of security due to additional layers being in place and once the Google team move to regular releases with a support lifecycle, I think it'll be quite a good option where it works to provide additional isolation for production workloads (for some production environments, the idea of picking a nightly build to use might not fit too well)
One tradeoff to consider for things like gVisor/kata/firecracker is that they don't have the same composable security model used in standard linux containers, so it's not always possible to remove a single part of the isolation (e.g. running with host networking) whilst leaving the rest of it in place
Everything I've read about Docker has given me the impression that they started seriously worrying about security only after they had already laid out the foundations, and that that meant they could never truly make it secure, resulting in lots of security holes that are found on an ongoing basis. Meaning I shouldn't rely on it when security is at stake. Is this wrong?
It would be fairer to say they weren't initially trying to provide a security layer. More like an alternative packaging system that was distro independent.
The idea was that such a packaged system should be doing all the security things you'd do if running on the bare operating system. So getting root inside a container would be expected to be as devastating as if the host had been compromised. Admittedly many developers didn't get this memo in the beginning.
So the Docker security team did a lot of work in the early days precisely because people felt that it didn't provide good security isolation.
As to root in a container == host compromise, what makes you say that? Absent a Linux kernel vuln. or mistake when running the container that's generally not easily possible.
(that's not to say that containers should be run as root, they should not, but that it's not necessarily trivial to breakout of one)
Simply because Docker was never supposed to be an isolated sandbox in the first place, rather a way to run trusted code as you normally would, just with consistent and reproducible dependencies.
The Docker team did quite a bit of work (e.g. establishing Apparmor/SELinux profiles, creating seccomp policies, deciding on acceptable capabilities) in the relatively early days of Docker. TBH those haven't changes much in quite a few versions now (AFAIK), so a lot of the foundational work was done early on.
There was a time when docker was production ready and the security check of containers was merely a stub that acted like it was checking things but didn’t really do anything. Please don’t rewrite history
I had assumed this article would have a Palo Alto sales slant to it, but it doesn't seem to - I'm very pleasantly surprised with the quality of the content, and found it very interesting.
And in contrast with another commenter here, I'm glad this was a to-the-point, no nonsense article - no stupid GIFs or too many cringey attempts at humour.
In the case of this article, in the Docker section there's no mention of the Apparmor/SELinux policy that gets applied to containers and no mention of the seccomp policy that's used by default to constrain some syscalls from a running container.
My general take on it is that Docker/LXC provide quite flexible security models, which can be modified to suit a user's process (e.g. by dropping unneeded capabilities from the default set or adding a custom seccomp profile)
gvisor provides a higher level of security due to additional layers being in place and once the Google team move to regular releases with a support lifecycle, I think it'll be quite a good option where it works to provide additional isolation for production workloads (for some production environments, the idea of picking a nightly build to use might not fit too well)
One tradeoff to consider for things like gVisor/kata/firecracker is that they don't have the same composable security model used in standard linux containers, so it's not always possible to remove a single part of the isolation (e.g. running with host networking) whilst leaving the rest of it in place