
Making Containers More Isolated: An Overview of Sandboxed Container Technologies - kiyanwang
https://unit42.paloaltonetworks.com/making-containers-more-isolated-an-overview-of-sandboxed-container-technologies/
======
rtempaccount1
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

~~~
mehrdadn
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?

~~~
ChrisSD
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.

~~~
Thaxll
Root in a container is not unsecure, the user mapping is different between
what runs the container and what's running inside.

~~~
ChrisSD
Again, I was talking about Docker's initial security considerations. I think
it wasn't until about 1.10(?) that it got user namespacing.

------
sbisson
They seem to have missed one key container isolation technology; Microsoft's
Hyper-V isolation as used on Azure: [https://docs.microsoft.com/en-
us/virtualization/windowsconta...](https://docs.microsoft.com/en-
us/virtualization/windowscontainers/manage-containers/hyperv-container)

------
GordonS
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.

------
dankohn1
Here are all the container runtimes that CNCF is tracking:
[https://landscape.cncf.io/category=container-
runtime&format=...](https://landscape.cncf.io/category=container-
runtime&format=card-mode&grouping=category)

------
New-user-123
Does anyone else find this article super dry and boring. I maybe read 5
sentences before I decided I just can't read this.

------
oyebenny
In case anyone was wondering, the Netflix cyber crime show "Unit 42" is quite
good.

