Containers vs Hypervisors: The Battle Has Just Begun (Linux.com)

Posted Aug 29, 2014 12:52 UTC (Fri) by Cato (guest, #7643)
In reply to: Containers vs Hypervisors: The Battle Has Just Begun (Linux.com) by dgm
Parent article: Containers vs Hypervisors: The Battle Has Just Begun (Linux.com)

No, but Google has open sourced some interesting cloud components recently, such as http://www.wired.com/2014/06/google-kubernetes/ - and of course there are Go, Dart, Chrome and many other technologies.

Containers vs Hypervisors: The Battle Has Just Begun (Linux.com)

Posted Aug 29, 2014 18:54 UTC (Fri) by Lennie (subscriber, #49641) [Link] (4 responses)

They didn't open source what they were using internally.

They created new code to do similar things they are doing internally and open sourced that. To be able to create a community around the project.

Just like Docker wasn't used internally by dotCloud, they created something new they wanted to create a community around.

Google also open source Let Me Contain That For You (lmctfy) and cadvisor in the same way. It's all new code.

In all cases their internal code most be years old and maybe not so pretty to look at, they probably wanted to start with a clear slate anyway without any legacy baggage.

Containers vs Hypervisors: The Battle Has Just Begun (Linux.com)

Posted Aug 30, 2014 0:22 UTC (Sat) by Sesse (subscriber, #53779) [Link] (3 responses)

cgroups, which Docker relies heavily on, is an open-sourcing of exactly the same kernel technology Google is using internally. But you are right, the userspace is different.

(Disclaimer: I work at Google, but not with anything related to this.)

/* Steinar */

Containers vs Hypervisors: The Battle Has Just Begun (Linux.com)

Posted Aug 30, 2014 9:00 UTC (Sat) by Lennie (subscriber, #49641) [Link]

Yes, of course cgroups was code that was used internally for, I believe a year, and then released as open source.

But it was clearly not developed in isolation. It is based on code and design from BULL/SGI and IBM. A lot of it was developed in the mainline Linux kernel too.

cgroups is a generalization of cpusets which was already in mainline. Which originally came from BULL SA. cpusets was later rewritten by SGI. That all happened before it was used by cgroups.

An other example is I believe the memory controller accounting (design ?) which came from IBM. The memory controller had a number of competing implementations, including beancounters by the OpenVZ guys.

Here is the original commit of cgroups:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/lin...

Also have a look at the end of this email from 2 years before cgroups was created:

For example, the following sequence of commands will setup a cpuset
named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
and then move the current shell to that cpuset:

mount -t cpuset none /dev/cpuset
cd /dev/cpuset/top_cpuset
mkdir Charlie
cd Charlie
/bin/echo 2-3 > cpus
/bin/echo 1 > mems
/bin/echo $$ > tasks

http://lwn.net/Articles/91637/

Looks kind of familiar, right ? ;-)

Containers vs Hypervisors: The Battle Has Just Begun (Linux.com)

Posted Sep 8, 2014 11:00 UTC (Mon) by dunlapg (guest, #57764) [Link] (1 responses)

The point is, a general purpose container -- one which gives you access to the full Linux system interface -- is only marginally more secure than not having any containers at all. Exploitable bugs, which allow you to execute code in the kernel (and thus bypass SELinux or any other security checks) are discovered in this interface basically every month.

The only way to make containers reasonably secure is to tailor the container to the exact program you're using, and then also to reduce the number of system calls required by that program. This can't be shared between applications; it needs to be done over again from scratch for *every new application*. The fact that Google has done this work for Google Docs doesn't benefit you at all when you're running Apache.

Containers vs Hypervisors: The Battle Has Just Begun (Linux.com)

Posted Sep 8, 2014 15:36 UTC (Mon) by Lennie (subscriber, #49641) [Link]

I don't know if every new application needs it.

I do know there is a long list of things you should do which could allow you to be somewhat secure.

If they implement all of the long list, would it be enough to run code from an untrusted source ? Maybe.

So far Google said they run customer supplied untrusted code for Docker in a Docker-container in a VM in a container.

Here is what RedHat's Dan Walsh is working on:
https://opensource.com/business/14/9/security-for-docker

Here is his list of tips at the end:

- Only run applications from a trusted source
- Run applications on a enterprise quality host
- Install updates regularly
- Drop privileges as quickly as possible
- Run as non-root whenever possible
- Watch your logs
- setenforce 1

He doesn't even mention the whole list, but as far as I can see. There is:
- cgroups to prevent a container to DOS CPU/Memory/disk for other containers
- seccomp to only allow certain syscalls:
https://github.com/docker/docker/blob/master/contrib/mkse...
- SELinux to only allow access to certain SELinux types and SELinux catagories
- capabilities whitelist to only allow certain capabilities
- readonly mounts to only a allow only a few entries from /sys /proc
- usernamespaces to make sure root in the container is not root to the kernel / outside the container - you'll need a fairly new kernel to be able to use it securely
- pid namespace to let the container only see it's own processes
- hostname namespace so the container has it's own hostname
- networking namespace to give the container it's own network stack

So far SELinux, capabilities, mounting /proc /sys readonly and namespaces (except for user) and I assume seccomp are implemented in Docker. Usernamespaces hasn't been implemented because not a lot of kernels running in the wild support it properly.