Hacker News new | ask | show | jobs
by nailer 3983 days ago
The security question (it's possible to break out of containers) isn't solved, and the workaround (use VMs) eliminates many of the advantages of containers and adds a massive burden.
2 comments

> it's possible to break out of containers

Prove it. I'm not saying it's impossible, but it's certainly not trivial.

Also, take a look at what Joyent are doing with Triton.

I was going to mention Triton/SDC. It does solve the security issues though it does it by running SmartOS. SDC is pretty cool but docker really needs to be secure in its own right.

It is also worth mentioning that since Joyent has implemented their own docker client, not all features are there yet. Last time I tried docker-compose didn't really work right yet. There is a full list of divergences on their github page. It has a lot of potential though.

> since Joyent has implemented their own docker client

Not our own docker client, our own Docker engine, https://github.com/joyent/sdc-docker , which was necessary for the whole DC to be the host. For a taste of the details see https://www.joyent.com/developers/videos/bryan-cantrill-virt... .

Your larger point is correct, we're still working hard every day to add increase the support particularly for the newer docker apis and extensions. Now, docker-compose 1.2 is working in the production datacenters with docker-compose 1.3 in the east-3b (beta) dc.

https://www.joyent.com/developers/triton-faq

https://github.com/joyent/sdc-docker/blob/master/docs/api/di...

I know that 'appeal to authority' is a bad argument technique but the Docker authors themselves have mentioned this repeatedly in the past. IIRC one of the holes was sysfs. Has something changed?
It's more that containers haven't been proven secure than that they are inherently insecure, so I disagree with the blanket statement "it's possible to break out of containers".

VMs have the advantage of shielding the kernel with a hypervisor, but they also have the disadvantage of lots of complicated driver code that can allow exploits such as VENOM.

For multitenant situations, sure. Still more isolation than running a bunch of services on the same box.
what is the benefit to any isolation of a process for a single tenant ? and why cant you just run cgroups without the overhead of docker ?

see : bocker

>what is the benefit to any isolation of a process for a single tenant?

Build, test, and ship the same artifact. Whether it's a Vagrant on your Mac, AWS, or metal in your colo datacenter.

>and why cant you just run cgroups without the overhead of docker ?

If you're running cgroups, you've created your own half-baked implementation of Docker in giving yourself a reasonable API to work with. This might make sense if you're Google but otherwise probably not.

cgroups is docker now ? what does that make systemd-nspawn ?
Docker is a simplified interface for controlling cgroups, yes. (Some people are working on/using alternative backends now, but that was the whole point at the beginning - a nice API for cgroups.)