I have some hosts that are swarmed together, and I'm trying to add the master to machine with -d none
. Everything has worked as expected so far, but the last bit I'm stuck on is that there's no way to specify the equivalent of --tlsverify=false
or DOCKER_TLS_VERIFY=
. This is my current workaround:
$ eval $( docker-machine env --swarm aws-stage | sed 's/"1"//g' )
Being able to specify this option during creation would be great; just having a field in the machine's config.json that I can manually edit is fine too.
rationale:
The server cert is generated by our infra team and is for a particular domain, but the hosts do not have DNS names assigned. So, I get the following outcome when TLS verification is enabled:
$ docker ps
FATA[0000] An error occurred trying to connect: Get https://10.128.47.21:3376/v1.18/containers/json: x509: cannot validate certificate for 10.128.47.21 because it doesn't contain any IP SANs
Could you try --engine-tlsverify=false
?
$ docker-machine --version
docker-machine version 0.4.0 (9d0dc7a)
$ docker-machine create localhost -d none --url unix:///var/run/docker.sock --engine-tlsverify=false
.. prints usage, does nothing ...
Hi @dobesv, the problem you are having is that before 0.5.0, trailing options (after the machine name) would be ignored without a warning. Please try docker-machine create -d none --url unix:///var/run/docker.sock --engine-tlsverify=false
localhost`. Even better, upgrade to 0.5.0
@mikedougherty any update on this issue? Did you try 0.5.0?
Hi all, sorry, I've been very busy lately. I will give this a try ASAP. Thanks for the feedback so far
There's no option called --engine-tlsverify
. I also tried --engine-opt tlsverify=false
and --engine-env tlsverify=false
DOCKER_TLS_VERIFY
is always set to 1
.
TlsVerify
on the created daemons today is always set to true.
I did give this another try today and I'm still unable to do this, though the reason seems clear. Unfortunately due to another issue (#2270) it's difficult for me to test if manually changing config.json to have "TlsVerify": false
will accomplish what I need. This would be a reasonable workaround, though it'd be better if those engine-opt
settings would take effect on create
:)
Tried to change tlsverify to false with --engine-opt when using the virtualbox driver but it will only add options to the current settings, which becomes --tlsverify=false --tlsverify...
Using build 1b76a44
root 2389 0.7 3.5 136144 35892 ? Sl 07:11 0:00 /usr/loca
l/bin/docker daemon -D -g /var/lib/docker -H unix:// -H tcp://0.0.0.0:2376
--label provider=virtualbox --tlsverify=false --tlsverify --tlscacert=/va
r/lib/boot2docker/ca.pem --tlscert=/var/lib/boot2docker/server.pem --tlske
y=/var/lib/boot2docker/server-key.pem -s aufs
I'm giving up on docker-machine, but for those interested, on Vagrant you can just manage the daemon's settings _after_ it's been provisioned:
$ docker-machine ssh <machine-id>
$ sudo vi /var/lib/boot2docker/profile # set DOCKER_TLS=no
$ sudo /etc/init.d/docker restart
$ exit
Then run docker-machine env <machine-id>
to see the recommended settings, but modify it to the following:
export DOCKER_TLS_VERIFY="0"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_MACHINE_NAME="my-machine-id"
Drop DOCKER_CERT_PATH from your environment and enjoy your TLS-free docker vm. Hope this helps!
@bacongobbler to be fair, you can do the same thing after the fact on any host provisioned by docker-machine. Also worth mentioning is that the goal here isn't a TLS-free docker connection, but rather one which does not verify the endpoint. Your solution will work for certain desired configurations but does not address the problem of a TLS-enabled daemon that is not verified by the client.
Sorry! I missed that requirement in the OP. I was just looking for a way to shut off TLS altogether since I just want plain tcp connections from my laptop to my vbox machine. This wasn't configurable so I opted for the above.
Judging by @nathanleclaire's comment it seems clear that this probably won't be something that can be configured through machine any time soon. You'll be better off with a DIY config management solution (as you've been doing, I'd assume) for the time being, IMO.
I'd like to +1 this - I use local sockets set up with socat
via ssh-agent (gpg-agent) HSM-based ssh connections to machines - eschewing TLS for docker entirely, sticking with ssh+agent. I can't risk access to these machines if local malware steals client keys.
I'm using --url
to point to the local sockets I've set up for the various remotes, but it still insists on TLS, which is not set up on the hosts. (I manually installed docker.)
tyrell:~â–» docker-machine create -d none --url unix://${TMPDIR}/ber1.docker.sock --engine-env tlsverify=false ber1
Running pre-create checks...
Creating machine...
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env ber1
tyrell:~â–» docker-machine env ber1
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "": open /Users/jp/.docker/machine/machines/ber1/server.pem: no such file or directory
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.
tyrell:~â–» docker-machine -v
docker-machine version 0.6.0, build e27fb87
tyrell:~â–» docker-machine create -d none --url unix://${TMPDIR}/ber1.docker.sock --engine-tlsverify=false ber1
Incorrect Usage.
Usage: docker-machine create [OPTIONS] [arg...]
Create a machine
Description:
Run 'docker-machine create --driver name' to include the create flags for that driver in the help text.
Options:
--driver, -d "none" Driver to create machine with.
--engine-env [--engine-env option --engine-env option] Specify environment variables to set in the engine
--engine-insecure-registry [--engine-insecure-registry option --engine-insecure-registry option] Specify insecure registries to allow with the created engine
--engine-install-url "https://get.docker.com" Custom URL to use for engine installation [$MACHINE_DOCKER_INSTALL_URL]
--engine-label [--engine-label option --engine-label option] Specify labels for the created engine
--engine-opt [--engine-opt option --engine-opt option] Specify arbitrary flags to include with the created engine in the form flag=value
--engine-registry-mirror [--engine-registry-mirror option --engine-registry-mirror option] Specify registry mirrors to use
--engine-storage-driver Specify a storage driver to use with the engine
--swarm Configure Machine with Swarm
--swarm-addr addr to advertise for Swarm (default: detect and use the machine IP)
--swarm-discovery Discovery service to use with Swarm
--swarm-host "tcp://0.0.0.0:3376" ip/socket to listen on for Swarm master
--swarm-image "swarm:latest" Specify Docker image to use for Swarm [$MACHINE_SWARM_IMAGE]
--swarm-master Configure Machine to be a Swarm master
--swarm-opt [--swarm-opt option --swarm-opt option] Define arbitrary flags for swarm
--swarm-strategy "spread" Define a default scheduling strategy for Swarm
--tls-san [--tls-san option --tls-san option] Support extra SANs for TLS certs
--url URL of host when no driver is selected
flag provided but not defined: -engine-tlsverify
tyrell:~â–» docker-machine create -d none --url unix://${TMPDIR}/ber1.docker.sock ber1 --engine-tlsverify=false
Invalid command line. Found extra arguments [--engine-tlsverify=false]
Any news here in 2017? Still not able to disable TLS for pre-create remote docker host
Any news here in 2017? Still not able to disable TLS for pre-create remote docker host
I am not maintainer anymore, but I have to say it again: Do not disable TLS on Docker for a remote host (preferably for any host, as hitting local things from the browser etc. is not difficult). If you do you are just giving away root access to your box to anyone on the Internet, and you can bet that folks are actively scanning for it.
Why do you think that every box has access from the internet? we have pure internal docker ecosystem for local development and automated testing without access from the internet. All the boxes run without TLS support as there is no need in management of certs for dynamic-generated docker-hosts and there is no real profit from TLS usage. And I can't add that docker machine to the local agent to manage them
Hello, anyone got it?
IDK but is the argument against supporting non-TLS docker servers that it is simply unsafe to run any docker server unsecured on port 2375, at home or in any shared network?
It's too easy for malware from email, web, and messaging or hacked machines in corporate networks to exploit a docker server on 2375.
The TLS port 2376 requires a trusted client certificate. I think it's relatively safe to leave that port open on an untrusted network?
still could not connect existed 2375 host in 2018.8
Neither in March 2019 :(
Most helpful comment
Why do you think that every box has access from the internet? we have pure internal docker ecosystem for local development and automated testing without access from the internet. All the boxes run without TLS support as there is no need in management of certs for dynamic-generated docker-hosts and there is no real profit from TLS usage. And I can't add that docker machine to the local agent to manage them