For web hosting, my company is looking to use docker containers for each web application with a reverse proxy as front-end. It works but we are looking for a way to let our users manage their own applications, admins will control public and private accesses via the reverse proxy and the dns.
But we cannot let the user the authorization to start/stop docker instances, as user which can send command to a docker daemon can do whatever he wants (as described here and here).
So how can we let user handles start/stop and configuration of some specific docker containers ?
The only solution at the present time (found here) is to let docker detect change in the registry to download and restart updates, for instance with Watchtower).
Another alternative is to wait for the user namespace support to avoid that root container user can access root host user, but will it be enough ?
edit: docker is not so strong for security but in our case:
- Users are limited to authenticated internal employees
- Users cannot directly access to the docker daemon (this the point of my question)
- It is a better solution that the one-instance apache with hundred vhosts
- We need to deal with demands about alternatives web framework / exotic configuration (node.js, meteor, ruby) instead of the classical LAMP, and containers are great for developers to transfer their application to the hosting platform.
- This is an experiment we are conducting, we hope in the not so far future that solutions like project atomic and/or the support of user namespace will bring better guarantees.
You could possible add to your customer interface a option wich shows him the container he own and let him reboot his container via Docker Remote API
But this should only be an option if you have an secure user interface and an good user rights management.
Be aware that the Docker remote API will change in the next version 1.9 at the end of october. Roadmap 1.9