Counter docker's availability blunder

[CleanCut]

To work around the overzealous new docker policy (see the soapbox discussion below for more on that). I have to run the following command after every time I start boot2docker to allow non-TLS access to our internal container repositories on 10.x.x.x.

boot2docker ssh 'sudo sh -c "echo \"EXTRA_ARGS=\\\"--insecure-registry 10.0.0.0/8\\\"\" > /var/lib/boot2docker/profile && sudo /etc/init.d/docker restart"'

What can boot2docker do now to make the situation better?

• Add a default configuration to allow unencrypted access to all private IP addresses

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
127.0.0.1/32

• Add some option to boot2docker init or boot2docker up or make some new command that makes it straightforward to indicate "LET ME DOWNLOAD STUFF WITHOUT TLS FROM SOME SERVER"

What do I wish docker would ultimately do?

• Allow unencrypted access to all private IP addresses by default
• Add signing/hashing (like git) to address the integrity concerns, instead of trying to ratchet up confidentiality (TLS) and demolish availability (daemon-side whitelist requirement) to address the integrity concerns.
• Have some sensible default encryption use in the use cases where it actually makes sense to address the confidentiality concerns (which are not the same as integrity concerns)
• Make the sensible encryption easy to use. Hardcoded whitelists are not easy to use when you're talking about client usage.

Soapbox

In my internal development environment where I am trying to foster and promote the use of docker, my efforts were dealt a serious setback when the docker folks decided to put big hurdles in the way of using docker without TLS

Security consists of three things: Confidentiality, integrity, and availability.

Having allegedly failed to pay sufficient attention to the confidentiality aspect at the start, the docker folks have committed the classic blunder of overcompensating by going so overboard on the confidentiality aspect that they ran right into and demolished the availability aspect.

Having a big hurdle like a daemon-side configured whitelist for a site could be sensible for public IP addresses, but it is a really unreasonable hurdle for localhost and private IP addresses.

It's always a tricky balancing act, and I look forward to docker's security reaching a balanced state in the (hopefully near) future.

[SvenDowideit]

One possible solution to this, is to add a boot2docker --profile=filename init which might default to ~/.boot2docker/vm_profile, which is put into the userdata.tgz that is the default vm-disk payload.

this would then be able to be copied to the persistent /var/lib/boot2docker/profile on the first bootup (before the Docker daemon is started).

This would allow users to have a default set of options - registry-mirror, insecure-registry etc that would be used whenever they create a new vm.

it might be worth adding a similar option to auto-add a bootlocal.sh too - that way the users can customise almost anything.

[SvenDowideit]

ok, wrt your soapbox - you're talking about registry TLS - I was going to talk about the Docker daemon's Docker socket TLS, but that's not applicable here :)