5 ms·

I really don't like giving up the isolation of modern hypervisors, particularly those with Intel virtualization extensions. Docker (and LXC) seems like a huge s

by rdl 13y ago

I really don't like giving up the isolation of modern hypervisors, particularly those with Intel virtualization extensions. Docker (and LXC) seems like a huge step backwards for security. I'm sure there are use cases, but I'd never multi-tenant with it.

shykes 13y ago
> I really don't like giving up the isolation of modern hypervisors You don't have to! Think of docker as a unit of software delivery, rather than resource allocation. It's very common to use Docker to either a) deploy only trusted containers on the same machine, or b) deploy only 1 container per machine. There are also cases where linux cgroups and namespaces are an appropriate security mechanism (usually combined with other best practices, like apparmor/grsec/selinux, network lockdown, active monitoring, running things as non-root etc.) but it's not mandatory. Here's our latest overview of container security: http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/ http://blog.docker.io/2013/08/containers-docker-how-secure-a...
- mtam 13y ago
  How about OS patching? If I am running hundreds of different containers and I need to patch the OS (let's say upgrade the kernel or a driver), will I affect hundreds of applications at once? If so this will be a problem for several shops. How about built-in failover? On a virtualized environment you can run a cluster and the VM will move to another host in case of failure. Does docker support that? Is that what the docker-cluster project (https://github.com/globocom/docker-cluster https://github.com/globocom/docker-cluster) is about?
  - lotyrin 13y ago
    OS updates (updates to files inside containers) would be on a per-container basis. Kernel upgrades would affect all of the containers running under that kernel (machine or VM) at the same time. Though, if you wanted to be super cautious, you could upgrade kernel on an empty container host (quite easy if virtualized) and migrate containers to it and test them on an individual basis.
vidarh 13y ago
I agree with you, but at the same time a I run a "private cloud" with 100+ containers at any one time. We do "sort-of" multi-tenant: There are multiple customers, but we run all of their services, so nobody outside of our organization needs os level access to the vm/containers. For "real" multi-tenant systems, I'd want full VMs, but as noted elsewhere, you can run Docker containers inside a VM, and still benefit from sharing resources by carving up a large VM into many smaller, isolated subsets. We run OpenVz today, but I'm following Docker closely as we plan to migrate to LXC, and then going for Docker might very well be the best alternative.
sarnowski 13y ago
> Docker (and LXC) seems like a huge step backwards for security. Sry but link says it all. No further comment from me: http://marc.info/?l=openbsd-misc&m=119318909016582&w=2 http://marc.info/?l=openbsd-misc&m=119318909016582&w=2
- rdl 13y ago
  VT-d, VT-x. 2007 != 2013. The number of hypervisor exploits is far fewer than the number of local root exploits on various shitty OSes (including OpenBSD).
  - sarnowski 13y ago
    Do you have a link for this statistic? Since I don't know of a local root privilege escalation since several years in OpenBSD, this is a quite high mark. Edit: this is not a os-or-vm problem. You will have local problems and now, in addition, rooting a server may give you access to even more servers that run on your hyp.
- j_s 13y ago
  I don't think that your link disagrees with the OP at all. Yes, bare metal is more secure than hardware virtualization; but hardware virtualization still provides greater security than kernel virtualization.

by rdl 13y ago

shykes 13y ago

> I really don't like giving up the isolation of modern hypervisors You don't have to! Think of docker as a unit of software delivery, rather than resource allocation. It's very common to use Docker to either a) deploy only trusted containers on the same machine, or b) deploy only 1 container per machine. There are also cases where linux cgroups and namespaces are an appropriate security mechanism (usually combined with other best practices, like apparmor/grsec/selinux, network lockdown, active monitoring, running things as non-root etc.) but it's not mandatory. Here's our latest overview of container security: http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/ http://blog.docker.io/2013/08/containers-docker-how-secure-a...

mtam 13y ago
How about OS patching? If I am running hundreds of different containers and I need to patch the OS (let's say upgrade the kernel or a driver), will I affect hundreds of applications at once? If so this will be a problem for several shops. How about built-in failover? On a virtualized environment you can run a cluster and the VM will move to another host in case of failure. Does docker support that? Is that what the docker-cluster project (https://github.com/globocom/docker-cluster https://github.com/globocom/docker-cluster) is about?
- lotyrin 13y ago
  OS updates (updates to files inside containers) would be on a per-container basis. Kernel upgrades would affect all of the containers running under that kernel (machine or VM) at the same time. Though, if you wanted to be super cautious, you could upgrade kernel on an empty container host (quite easy if virtualized) and migrate containers to it and test them on an individual basis.

vidarh 13y ago

I agree with you, but at the same time a I run a "private cloud" with 100+ containers at any one time. We do "sort-of" multi-tenant: There are multiple customers, but we run all of their services, so nobody outside of our organization needs os level access to the vm/containers. For "real" multi-tenant systems, I'd want full VMs, but as noted elsewhere, you can run Docker containers inside a VM, and still benefit from sharing resources by carving up a large VM into many smaller, isolated subsets. We run OpenVz today, but I'm following Docker closely as we plan to migrate to LXC, and then going for Docker might very well be the best alternative.

sarnowski 13y ago

> Docker (and LXC) seems like a huge step backwards for security. Sry but link says it all. No further comment from me: http://marc.info/?l=openbsd-misc&m=119318909016582&w=2 http://marc.info/?l=openbsd-misc&m=119318909016582&w=2

rdl 13y ago
VT-d, VT-x. 2007 != 2013. The number of hypervisor exploits is far fewer than the number of local root exploits on various shitty OSes (including OpenBSD).
- sarnowski 13y ago
  Do you have a link for this statistic? Since I don't know of a local root privilege escalation since several years in OpenBSD, this is a quite high mark. Edit: this is not a os-or-vm problem. You will have local problems and now, in addition, rooting a server may give you access to even more servers that run on your hyp.
j_s 13y ago
I don't think that your link disagrees with the OP at all. Yes, bare metal is more secure than hardware virtualization; but hardware virtualization still provides greater security than kernel virtualization.