There's a reason we keep saying docker is not yet production-ready.
Right now our focus is on usability and stabilizing the management API to make deployment-centric deployment awesome. You can be sure that before we tell anyone that they can use docker to sandbox untrusted code in a shared environment (which by the way is not the only use case of docker) we will be locking down our default lxc configuration and doing a sweep of all pending security issues.
For the record, we (dotCloud) have tens of thousands of lxc containers currently running untrusted code in production on shared infrastructure, and have had to monitor and maintain them 24/7 for several years. Before that we ran openvz. And before that, we ran vserver. So while docker itself may not yet be ready for production (and indeed we don't use it in production at dotcloud either), you don't need to worry about our stance on security. We care about it just as much as you do.
Before that we ran openvz. And before that, we ran vserver.
If you have a minute and can share, I'd love to hear why you switched away from vserver (and then openvz but especially vserver). Or maybe you have those transitions written up somewhere?
Sure - for openvz it was more powerful resource accounting and limits (this is back in 2008). I think there was extra goodness around networking, but honestly I can't remember. Mostly we were trying to figure out which project would find its way into mainstream, so we could standardize on that. vserver had been around forever and somehow never made it in, so OpenVZ looked like our best bet. Of course we turned out to be wrong :)
Good question - no, we don't. Developers can request for certain whitelisted commands to be executed within an environment that we know to be safe. For example, you can specify a list of system packages, and dotcloud will install them from the official LTS Ubuntu repository.
There's an ongoing discussion in the Docker community on the best way to make this possible in a shared environment. One possibility is to add support for OpenVZ, which has a better track record on that front (although it's not clear how much of the perceived difference is just fud). Another is to combine namespaces with SELinux, so that even if you break out of the namespace, you're stuck in a "limbo" context with no ability to do harm. Lastly, there's the possibility of extra instrumentation around the container, to limit the risk - for example you could allow root privileges only for a whitelist of commands on a whitelist of base images. Or you could only authorize network connectivity with a whitelist of remote hosts (keeping in mind most use cases which require root access involve short-lived image building). Or you could map containers with root privileges to dedicated virtual machines, separately from the unprivileged containers. Etc.
To clarify, I'm talking about our use of containers at dotCloud, which is a multi-tenant environment.
Docker _does_ allow running processes as root inside a container, and it also allows dropping privileges to the uid of your choice. It all depends on your particular use case.
Docker allows 'everything' minus the explicit list linked to in the article. What it should do is allow an explicit list, which recently became possible.
Just a heads-up: I know this isn't your fault, but docker.io does not say this on the front page, About, or FAQ that I can see. In fact, it currently says "same container that a developer builds and tests on a laptop can run at scale, in production".
Docker looks very interesting, thanks for your work.
That's a good point! The website is maintained separately from the rest of the project so I don't have direct visibility over it (I'm the lead maintainer of docker). I should have checked this earlier. Thank you!
Comments
Hi, docker maintainer here.
There's a reason we keep saying docker is not yet production-ready.
Right now our focus is on usability and stabilizing the management API to make deployment-centric deployment awesome. You can be sure that before we tell anyone that they can use docker to sandbox untrusted code in a shared environment (which by the way is not the only use case of docker) we will be locking down our default lxc configuration and doing a sweep of all pending security issues.
For the record, we (dotCloud) have tens of thousands of lxc containers currently running untrusted code in production on shared infrastructure, and have had to monitor and maintain them 24/7 for several years. Before that we ran openvz. And before that, we ran vserver. So while docker itself may not yet be ready for production (and indeed we don't use it in production at dotcloud either), you don't need to worry about our stance on security. We care about it just as much as you do.
If you have a minute and can share, I'd love to hear why you switched away from vserver (and then openvz but especially vserver). Or maybe you have those transitions written up somewhere?
Sure - for openvz it was more powerful resource accounting and limits (this is back in 2008). I think there was extra goodness around networking, but honestly I can't remember. Mostly we were trying to figure out which project would find its way into mainstream, so we could standardize on that. vserver had been around forever and somehow never made it in, so OpenVZ looked like our best bet. Of course we turned out to be wrong :)
There's a related discussion here: https://news.ycombinator.com/item?id=6227937
Do you allow any of that untrusted code to run AS ROOT within a container, though? (If so: what capabilities do you allow it to have?)
Good question - no, we don't. Developers can request for certain whitelisted commands to be executed within an environment that we know to be safe. For example, you can specify a list of system packages, and dotcloud will install them from the official LTS Ubuntu repository.
There's an ongoing discussion in the Docker community on the best way to make this possible in a shared environment. One possibility is to add support for OpenVZ, which has a better track record on that front (although it's not clear how much of the perceived difference is just fud). Another is to combine namespaces with SELinux, so that even if you break out of the namespace, you're stuck in a "limbo" context with no ability to do harm. Lastly, there's the possibility of extra instrumentation around the container, to limit the risk - for example you could allow root privileges only for a whitelist of commands on a whitelist of base images. Or you could only authorize network connectivity with a whitelist of remote hosts (keeping in mind most use cases which require root access involve short-lived image building). Or you could map containers with root privileges to dedicated virtual machines, separately from the unprivileged containers. Etc.
To clarify, I'm talking about our use of containers at dotCloud, which is a multi-tenant environment.
Docker _does_ allow running processes as root inside a container, and it also allows dropping privileges to the uid of your choice. It all depends on your particular use case.
what capabilities do you allow it to have?
Docker allows 'everything' minus the explicit list linked to in the article. What it should do is allow an explicit list, which recently became possible.
Just a heads-up: I know this isn't your fault, but docker.io does not say this on the front page, About, or FAQ that I can see. In fact, it currently says "same container that a developer builds and tests on a laptop can run at scale, in production".
Docker looks very interesting, thanks for your work.
That's a good point! The website is maintained separately from the rest of the project so I don't have direct visibility over it (I'm the lead maintainer of docker). I should have checked this earlier. Thank you!
Very well done, Solomon. I really admire what dotCloud is doing in this space.
Cheers,