--insecure-registry should be on "docker pull"

[abourget]

Hi folks, thanks for all your great work.

I was previously running a "library/registry" on localhost:5000. With Docker 1.3+, I was required to run docker with --insecure-registry localhost:5000. Doing so did nothing, until I discovered I needed to run docker, as in daemon, with those parameters.

It would be very useful to have that handled directly by docker pull, and not have to restart the whole thing and tweak system-level settings when you discover you need to use a local unsecure registry. EDIT: As mentioned in the comments, it would also be very useful to allow any registry to be unsecure, not just named ones, as Docker sometimes provides random ports, and some environments have many registries popping in and out of existence.

It is currently read here: https://github.com/docker/docker/blob/master/docker/daemon.go#L43 (while running the daemon), and it's checked while pulling in https://github.com/docker/docker/blob/master/graph/pull.go#L116 .. maybe we could add yet another switch to pull like --insecure and tweak that would forcefully make it secure == false ?

I don't have a docker development setup ready, but if you think it's a good idea.. I could try to implement it.

Linux cerise 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Docker version 1.3.1, build 4e9bbfa
Containers: 5
Images: 607
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 618
Execution Driver: native-0.2
Kernel Version: 3.13.0-32-generic
Operating System: Ubuntu 14.04.1 LTS
Debug mode (server): false
Debug mode (client): true
Fds: 10
Goroutines: 11
EventsListeners: 0
Init Path: /usr/bin/docker
Username: abourget
Registry: [https://index.docker.io/v1/]
WARNING: No swap limit support

[octalthorpe]

We run internal unsecured docker registries in all CI and production environments. I must say that it would be very usefull to simply enable access to all insecure registries without having to list them out one by one. We have multiple registries in each environment for HA. This change has made things much more complicated for us. I am going to open another issues ticket that specifically to address that, as this issue is more to move the option to the pull rather than on the daemon.

[proppy]

And there is a bit of a chicken and egg problem when you don't use a fixed port for running the registry.

Since you don't know which port will get assigned by docker in advance, you can't really start the demo with a flag that reference it.

[reinh]

👍

[abourget]

so I guess supporting --insecure on the docker pull command line, forcefully disabling security checks, obviously for this pull command, would also solve you problem @proppy and @octalthorpe right ? as running with this flag wouldn't check lists whatsoever

[proppy]

@abourget it also need to be supported in the remote API.

Currently docker-py expose an insecure_registry flag on the pull function, but it's only used to resolve the endpoint: https://github.com/docker/docker-py/blob/master/docker/client.py#L794

[proppy]

The culprid seems to be 6a1ff02

But I couldn't find the corresponding PR or issues where that change was discussed.

@tiborvass any ideas?

[ewindisch]

@proppy - This was handled as an embargoed security vulnerability and was not discussed in a public PR. The core team had visibility and vote on the issue.

I need to contemplate on the implications of such a change for localhost/127.0.0.1, but I'm not particularly keen on it. It's a non-standard, uncommon configuration and the solution is well-documented.

[proppy]

@ewindisch on the other hand there is a lot of docker daemon already running, with registry container running on localhost.

If literally all those users will need to pass --insecure-registry localhost:5000, you might as well make it the default.

[mmdriley]

@ewindisch Do you folks have documentation or guidance for what constitutes an embargo-class vulnerability? This isn't remote, unauthenticated RCE. The danger here doesn't seem nearly acute enough to justify a breaking change in a point release with no warning.

[ewindisch]

@mmdriley - the definition according to Mitre/NST generally applies. In this case, a man-in-the-middle attack is viable which allows the execution of arbitrary untrusted code on affected systems, so yes, we do classify this as a RCE. This means that if you were to use Docker to pull images on a laptop in a cafe, for instance, that another user of that WiFi access point could potentially run arbitrary applications provided by an attacker. They could also potentially gain access your DockerHub account or other registries to which you would authenticate.

EDIT: adding link for CVE description: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

[mmdriley]

Yep, I was wrong to say this wasn't RCE. It's a bad bug, and a great testament to why robust image signing is a great idea. However, exploitation isn't trivial: it requires an active attacker to hang out at Starbucks hoping someone nearby will use Docker over insecure WiFi. This isn't going to be weaponized overnight -- and therefore doesn't merit a backwards-incompatible change with no warning.

As has been suggested above, there were obvious ways to improve security immediately without breaking compatibility. For example, disabling HTTPS fallback for index.docker.io and the handful of other popular public registries would have effectively solved the problem for most users. Adding a warning to the console output that HTTP fallback was happening would have mitigated the interactive case. HTTP fallback would be marked deprecated and removed in, say, next month's release. Finally, localhost and ::1 are obviously not vulnerable.

Again, I shouldn't have discounted the extent of the vulnerability, but I'm worried that the response process and the fix didn't put enough value on not breaking customers.

[jwthomp]

We our currently creating/destroying docker registries dynamically in an environment that does not have FQDN available to many of these instances. Supporting a --insecure-repository option for registry related requests (over remote API) would remove significant complications this security fix has created for us.

[kruxik]

We have similar problem with Docker 1.3.1. We use local (private) Docker registry on the address http://docker:5000/. Until Docker 1.3.0 it worked just fine. With Docker version 1.3.1 it doesn't work anymore because Docker client automatically assumes Registry is reachable on HTTPS. But we don't use HTTPS at all.

It would be nice to implement a fallback mechanism which uses HTTP if a Docker Registry servers is not accessible via HTTPS.

[tiborvass]

@kruxik if you use --insecure-registry docker:5000 when starting the daemon, it will fallback to HTTP.

[kruxik]

@tiborvass thank you for the suggestion. You are correct. But if you have a lot of developers with their workstations and notebooks, setting --insecure-registry on each station is a way impractical. At least let it as an optional parameter for pull/push operations would be sufficient for us ;)

[epankala]

+1

This worked for us with 1.3.0, but with 1.3.1

docker version
....
Server version: 1.3.1
....
docker push 10.121.4.236:5000/debian7/consul
-> ....If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add --insecure-registry 10.121.4.236:5000 to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at

Downgrade
Server version: 1.3.0
docker push 10.121.4.236:5000/debian7/consul
-> container uploads without problems.

[mhamrah]

For others having issues with the 1.3.0 to 1.3.1, I had to make the following changes for OS X with boot2docker:

$ boot2docker delete #removes old image
$ rm -f ~/.ssh/id_boot2docker* # remove old keys
$ boot2docker init #generates new keys, cert
$ boot2docker up
$ boot2docker ssh
$ # add EXTRA_ARGS="--insecure-registry <YOUR INSECURE HOST>" 
$ # to /var/lib/boot2docker/profile
$ sudo /etc/init.d/docker restart

then you should be able to do a docker pull.

If using fig, you also need Fig 1.0.1 and do:

$ fig up --allow-insecure-ssl

[jdongelmans]

@mhamrah Thanks! Spent hours trying to fix this...

[thockin]

+1 to assuming localhost is secure. Is anyone actually against this?

[jasonwatt]

Yea, assuming localhost is secure would help a lot. i use vagrant for my docker box, so updating the init script every time i destroy or bring up a box is just inefficient. I guess i will now have to puppetize my docker box so that i can modify the init on the vagrant up.

also using an --insecure flag on the pull and push would be nice so i could use the vagrant box IP if needed.

[proppy]

@Thocking: le assuming localhost is secure: please see #8898

[bjneuhaus]

To be honest I also was wondering why my automated Jenkins Containerbuilds failed in pushing...
(Good to have a testenv. before putting it to production).
I have to check if this "feature" was really annouced - if not I will be more paranoid on so extreme massive changes on daemons behaviour.

What I miss in this discussion:
Why I even have to tell the daemon to use "default" secure / unsecure mode for each host?

Shouldn't it be more productive to setup the registry with this default behaviour?
So depending on the setup if no --secure or --insecure parameter is given the daemon should request
if secure way is possible and if not that the fallback to unsecure was used .

One of the main things of docker is that it's completly easy to use and to setup a complete env. please don't kill this WOW effect with such "releases / decisions"...

just my 2 cents...

[jaytaylor]

Is there a PR open for this?

[Ichimonji10]

Not AFAIK. The links above are generated because some of my own code references this issue. I'll pull that reference for a while to quiet down the spam here.

[waldman]

+1 as well...

[mmchen]

+1

[eromoe]

+1 , it is very inconvenient to add setting to deamon.json and restart docker.

Different machines have different os . Some install docker from yum 、apt-get , and some directly using binary . So I have to detect that and restart dockerd correctly .... that 's a disaster

I just stress docker pull need --insecure-registry flag !

[r-chris]

It's only been three years - let's not lose hope now

[justinclayton]

bump 🤣

[petr-stupka]

+1

[sherif84]

+1

[mmpfeffer]

The argument that this encourages users to set their registries as secure is not only presumptuous, it also missing a key point. It puts operations in the position where many people must have access to the root account in order to do their operations work, where docker registries are moving around a lot.
That coupling, from an operational security standpoint, creates greater security risk.

Secondly, in a private network (such as in a multi-tiered cloud-hosted application), the securing of registries is not necessary, and further complicates technology implementations which sit on top, requiring layers of security management (to handle automated docker authentication/refresh) wherever a secure docker registry is used.

At the very least, the docker daemon should be configurable to ALLOW insecure registry parameter to be passed in. That moves the security design to the proper place - in the hands of the administrator, and outside of docker itself.

[mjambon]

FWIW I'd be happy with a command to "add some registry to the list of insecure registries", since patching json configs from shell scripts is a major pain point.

[dmwoods38]

+1

[TintypeMolly]

👍 +1

[sakethkoduru]

+1

[yashpatel5400]

+1

[zulrang]

+1

[csegedicsaba]

+1

[ewindisch]

Many of the requested implementations of this would make it impossible for companies utilizing Docker to adhere to SOC compliance requirements, etc.

There should be a solution to this, but I don't think there's an easy solution that will not be a more drastic architectural change to how images are stored and executed.

Still, that should happen.

I'm no longer involved with Docker development so I'm gonna remove myself from the mentions. Good luck yall ^_^

[mmpfeffer]

The SOC requirement is a good point. In that case, this feature should be ENABLED with a configuration option to be added to the system-wide docker configuration. That way SOC requirements can be retained. Something like "ALLOW_INSECURE_REGISTY_OPTION" which enables the --insecure-registry flag on the docker command line.

[mmpfeffer]

For SOC compliance the option must not be enabled.

[shqear93]

+1

[grunzwei]

It's only been three years - let's not lose hope now

[thaJeztah]

This proposal (in its current form) is very unlikely to be implemented, for various
reasons, among which;

• it keeps the person managing the docker daemon in charge of what connections
  the daemon is allowed to make. note that this option can be "live reloaded",
  so the daemon does not have to be restarted in order to change the configuration.
• every command or code-path that potentially interacts with a registry will have
  to be modified; not just docker pull, but also docker build, docker run,
  docker plugin, docker service and docker stack subcommands, as well as
  orchestrators such as swarmkit, which pull images from worker nodes.
• SOC compliance (as mentioned above)

At the very least, the docker daemon should be configurable to ALLOW insecure
registry parameter to be passed in. That moves the security design to the proper
place - in the hands of the administrator, and outside of docker itself.

I think the administrator in this case would be the person/team managing the
hosts on which the docker daemon runs, not the user that connects to the remote
API. This is the reason for this configuration to be a daemon configuration.

patching json configs from shell scripts is a major pain point.

That's a fair point, but orthogonal to this discussion. It's not impossible
to patch the JSON config, but agreed that it can be more complicated than other
file formats. Note that this configuration can also be set as through flags on
the daemon, which allows you to use a systemd drop-in unit file to reconfigure
the daemon.

Something like "ALLOW_INSECURE_REGISTY_OPTION" which enables the --insecure-registry flag on the docker command line.

If you want to allow insecure pulls from any registry (which would be the equivalent
of adding an --insecure-registry flag), you can allow "the internet" as insecure
registry; the following should allow any IPv4 address to be used as insecure registry,
(thus fall back to non-TLS connections);

Through the /etc/docker/daemon.json configuration file;

{"insecure-registries": ["0.0.0.0/1","128.0.0.0/2","192.0.0.0/3","224.0.0.0/4"]}

Or by passing the options as flags on the daemon (which could be set in a systemd
override file);

dockerd \
    --insecure-registry=0.0.0.0/1 \
    --insecure-registry=128.0.0.0/2 \
    --insecure-registry=192.0.0.0/3 \
    --insecure-registry=224.0.0.0/4

[erfantkerfan]

+1

[babinos87]

Just came across this. We are running a private registry in AWS network, so we need to use internal DNS, when we access through a VPN and want to push images to this registry, it is impossible if we don't edit docker config, which is not ideal for the reasons mentioned by other people. We could go with plain HTTP, but this is even less secure than allowing an insecure registry (which is not so insecure in fact, it's only that the certificate used cannot be validated properly because of hos mismatch!).

Ideally, we would like to specify this extra flag in the docker push command, so no developer has to go through editing the docker configuration. I know it's not big deal, but adds an (unnecessary IMHO) level of complexity.

It seems this is an ongoing topic for many many many years, let's hope that on the issue's 10th anniversary it will have been resolved!

[andrask]

Actually, the fundamental issue here is the centralized daemon behavior of Docker. The daemon is not necessarily under the control of the actual user, thus security wise the current setup is probably the best solution. But over the years several alternative toolsets have emerged. For example, with Skopeo one can easily transfer images between registries. Alternatively, podman can do the same. Therefore, I think it is probably time to conclude this ticket with "rejected" and add notes about the alternatives.

[adamnovak]

A workaround for this, since registries on all ports of localhost are insecure by default, is to forward a port from localhost to the desired registry, pull from localhost, and then adjust the tags. So to pull whatever.tld/imageowner/imagename:tag from an insecure registry on whatever.tld port 80, you would do:

REGISTRY_HOST=whatever.tld
IMAGE_ON_REGISTRY=imageowner/imagename:tag
REGISTRY_PORT=80
PROXY_PORT=5050
socat tcp-l:${PROXY_PORT},fork,reuseaddr tcp:${REGISTRY_HOST}:${REGISTRY_PORT} &
docker pull localhost:${PROXY_PORT}/${IMAGE_ON_REGISTRY}
docker tag localhost:${PROXY_PORT}/${IMAGE_ON_REGISTRY} ${REGISTRY_HOST}/${IMAGE_ON_REGISTRY}
docker rmi localhost:${PROXY_PORT}/${IMAGE_ON_REGISTRY}
kill %1