Risks posed by docker daemon running as root
The docker daemon does run as root, as it interfaces with the host operating system in a farily fundamental manner, however that's no different than most/any system daemon that makes use of linux capabilities which require that privilege.
This doesn't mean that using docker is insecure, just that you need to be careful with how you use it. Luckily there is already some fairly good security configuration advice available on this from Docker themselves and in the form of a security configuration "best practices" guide from the Center for Internet Security
A couple of practical considerations which you do need to be aware of when running docker.
First up is that if someone is a member of the "docker" group on the host, they're effectively root on the system as it's possible to use docker to escalate privileges in this case. So you need to treat membership of that group on production hosts with care.
Docker uses Linux capabilities to restrict what actions a user inside a container can take, so just being root inside a container doesn't necessarily mean automatic root on the host. That said you do need to be careful with things like volume mounts (so if you mount a system directory from the host into a container for example) as this can allow a root user inside a container to make changes to files on the host.
You can also reduce the capabilities provided to a container fairly easily, which can improve the security of the process further.
Also remember you don't need to run processes in containers as root, you can run as other users with a bit of configuration, and this mitigates the volume mounting risk.
I find that the way to think about containers is as processes on the host. If you compare running things in containers to running them directly on the host, I'd say that the container architecture is likely to add security rather than remove it, as you've got a better defined interface between the process and the host and more control over what the process can do on the host.
Also it's worth nothing that a richer user mapping architecture is coming fairly soon to docker (planned for 1.9) which will add some more options for restricting actions in a container.
No, you aren't.
Or, put it another way, if you are mistaken to be concerned, there are a lot of security experts who are similarly mistaken. Just to take a few prominent examples:
-The experts interviewed here about Docker security, and specifically about the daemon root issue. Including a guy from CERT:
Yes, that's right, Docker, and many other container technologies, need root access to do their magic. And, like any other program that needs root access, with great power comes great opportunities to wreak havoc.
As Aaron Cois, a researcher at CERT at Carnegie Mellon University recently told the DevOps publication, "One of the biggest threats I see with Docker is its positioning and the implied security in the language. The reality is that these containers don’t contain anything." With root access that's indeed the case.
Also, running anything with root privileges within the container apparently is problematic "A process running as root (UID 0) in a container has root-level privileges on the underlying host when interacting with the kernel."
That piece provides a good bit more about the specifics of issues related to the daemon's root status in particular, and a good overview of the security issues that are a little worrisome with Docker in general.
-Here's a really good analysis from a team that talks about a number of security issues regarding Docker, including some directly related to the daemon-as-root architecture, and how to combat/mitigate them. The presenters here offer a mixed-to-somewhat positive view of Docker security in general, but they make it clear there are a number of possible threat-vectors that have to be on one's mind when creating a set-up.
You get the point, I think. (Google reveals plenty more pieces articulating those points, and I've personally read a few others here and there over the past year or so.) Now, I'm not bashing Docker by any stretch of the imagination, and it seems like if your careful in how you set up and maintain things you can greatly reduce the threats that Docker's less-than-rock-solid security architecture allows to exist, including deamon-as-root. (And certainly containers are easy & convenient to use as all-get-out.) But you are definitely, certainly not wrong to have some concerns about Docker not using a good, modern approach that includes maximum reasonable privilege-reduction (as Docker stands today, at least).
The article from Daniel Walsh, leader of the RHEL Docker enablement team (so not the kind of guy who would have any reason to fight against Docker), about Docker security is also interesting. One of the key thought is that one must "just assume that privileged processes running within the container are the same as privileged processes running outside of the container.".
This is a relatively old article, July 2014. Linux containers (on which relies Docker) have evolved and in January 2014 they introduced unprivileged containers ensuring that privileged process inside the container are now running with end-users privileges from the host system point-of-view.
However, this feature is still not supported in Docker and was postponed several times.
In another answer pertaining to Docker security I also mentioned several other security oriented projects which were relying on Docker before leaving it due to security issues.
So, as you said, Docker "promises to simplify our deployments and provide a number of other design and operational benefits", this is certainly true and seems to be the main goal for Docker, but as Daniel Walsh highlighted it security through isolation is not a part of these promises.
As often there is a compromise to be found between security and functionality. Docker seems to position itself on the functionality side of the ladder. It's up to you decide if the value added by Docker features worth it.