CoreOS Rocket announcement claim to fix a design / security issue within Docker. They didn't explained much, and as you can imagine this has been discussed during DockerCon.
Docker uses a one-does-all executable model, just like busybox does. Busybox is a minimalist Linux distribution design for embedded use, and as such provides a single executable to cover all common Unix commands. This significantly reduce the distribution size.
Docker did adopt the same model and provide a single "docker" command both for client and daemon - make sense as they share lot's of code to communicate on REST api. The design and security consideration comes on the fact Docker daemon runs as root. The daemon has to be root to manage Linux namespaces and cgroup and few other kernel level stuff (network, ...). From a security perspective having a root component exposed over HTTP(S) to get client commands on the network is unpleasant, and daemon does lot's of stuff that does not require to be root (downloading image layers for sample) that offer a larger surface attack. If you consider Apache httpd design (as a sample), main daemon run as root to bind port 80, but workers process run as non-root to prevent any abuse for http handlers and module possible security issues.
CoreOS point of view is SystemD should be used to manage containers, and the container manager doesn't have to be running as root and delegate to SystemD when some kernel-level container management stuff is required.
Solomon just tweeted this :
Docker uses a one-does-all executable model, just like busybox does. Busybox is a minimalist Linux distribution design for embedded use, and as such provides a single executable to cover all common Unix commands. This significantly reduce the distribution size.
Docker did adopt the same model and provide a single "docker" command both for client and daemon - make sense as they share lot's of code to communicate on REST api. The design and security consideration comes on the fact Docker daemon runs as root. The daemon has to be root to manage Linux namespaces and cgroup and few other kernel level stuff (network, ...). From a security perspective having a root component exposed over HTTP(S) to get client commands on the network is unpleasant, and daemon does lot's of stuff that does not require to be root (downloading image layers for sample) that offer a larger surface attack. If you consider Apache httpd design (as a sample), main daemon run as root to bind port 80, but workers process run as non-root to prevent any abuse for http handlers and module possible security issues.
CoreOS point of view is SystemD should be used to manage containers, and the container manager doesn't have to be running as root and delegate to SystemD when some kernel-level container management stuff is required.
Solomon just tweeted this :
 | solomonstre So who wants to help make Docker embeddable? Daemon mode would be optional if you prefer another central daemon to be in charge like systemd 06/12/2014 02:28 |
| solomonstre @solomonstre the difficulty is that some parts of "just run" require managing global system state, eg ip allocation. How do we do this? 06/12/2014 02:46 |
| solomonstre @solomonstre rocket sweeps this under the rug by putting it all in systemd. But I don't want to tie Docker to systemd, it's too monolithic 06/12/2014 02:48 |
That's a major point : SystemD does not enough so Docker daemon doesn't need to run as root, so can't just say "let's make Docker rely on SystemD". Also, Docker changed it's design in 0.6 to make the image persistence extensible, so you can use AUFS or device-mapper, maybe alternate Filesystem solution (ZFS for sample) will later plug into docker. Docker team doesn't want to have SystemD as unique solution. So as they use to : define a clean extension point with neutral API, provide a default implementation (current design, with docker daemon running as root) and offer extensibility so you can configure docker to run third-party implementation, maybe relying on SystemD, maybe on other solutions.
Today Docker team is organizing a Hackathon for people still at Amsterdam after DockerCon (~80 hackers have registered afaik). Not sure this will be enough to get this implemented during the week-end, but I expect this will be actively discussed and maybe some plan for a proposal.
