The current architecture of Docker Machine is set to assume success, not failure. This has been great to get started quickly, but as the Machine project has grown it has become more apparent that failure is the norm, not the exception. Docker Machine architecture should be set up to handle this, and also to account for the real-life situations of securing your cluster, accessing it from computers other than where it was created, and recovering from disastrous situations such as the deletion of ~/.docker.
- Assume failure, not success. Everything will fail all the time, act accordingly.
- Assume that everyone on the Internet is actively trying to kill you. "Secure by default" is the maxim.
- Enable users with nice interfaces without trying to conceal the underlying mechanics. Power users should be allowed to get into the plumbing.
- "No Admin Interfaces". If the user has to visit the VBox GUI, EC2 console, DigitalOcean admin panel, etc. then it's a bug in Docker Machine.
- Always maintain audit trails and logs with as much detail as possible. This is critical for support as well as debugging, and the sooner that Docker Machine can provide detailed answers about "who did what where when", the better.
Currently, anything that needs to be persisted for use by Docker Machine (certs, API authorization tokens, machine settings, SSH keys) goes through the Store struct in some fashion, whether it's implicitly or explicitly. A design goal of where Docker Machine goes in the future should be to decouple all of these: sensitive data (API keys) is kept alongside non-sensitive data as if it is a non-issue, Docker Machine provides no way to recover (even to a degraded state) in the case of the deletion of .docker, the state which is tracked in each machine's config.json is not reflective of the true state of the system, and so on.
Therefore, the fundamental architecture of the approach to "storing" things needs to be re-thought. Trying to scale the current method will result in tears down the line (it already is, actually).
To that extent I propose to "divide and conquer" by splitting the problem into various components, each engineered to promote resilience to the various types of failure possible:
- Persistent onfiguration of the Machine client via CLI (this improves UX and makes storing sensitive information such as secrets possible)
The user interface to machine in its current form is approachable and powerful: this provides
A common operation
Paraphrasing: "The best security is to put all of your eggs in one basket, and make it a really strong basket".
Drivers should use a distribution of:
All ports except for 2376 (the Docker TLS port) should be firewalled off by default,
The user which is provided by docker-machine ssh commands should be a regular, non-root-privileged user. This means that they will not be allowed to run Docker commands without sudo. Otherwise, we are offering root access on these boxes to anyone that has access to Docker Machine or the SSH private keys stored in ~/.docker.
The current implementation of auto-mounting /Users in the boot2docker ISO, while arguably neccessary to get something out of the door when it was first introduced (Docker 1.3.0), is problematic to end users for three reasons:
- Security. One of the best things about having a VM to run Docker commands in is safety: if you are tricked into running a malicious image (and, as more users adopt Docker, they inevitably will be- I have personally seen someone, otherwise a very smart person, copy-paste a
docker run --privilegedcommand with zero knowledge of the implications) then the damage to your host system is limited. Auto-mounting/Usersblows the doors wide open on this for attackers, offering up all of their SSH private keys, cloud provider API tokens (!), and whatever other juicy secrets the user happens to have laying around in/Users. There is no question of if this will be exploited, there is only a question of when. - Performance. Enough ink has been spilled on the poor performance of VirtualBox Shared Folders, so hopefully the fact that we need to provide users with at least an option for something better speaks for itself.
- Permissions and UID/GID mapping. You shouldn't have to be a UNIX guru to edit these settings, there should be another tool which makes it easier. Currently users have all kinds of issues with this and we should provide them with a way to configure things nicely.