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

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.

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.

:+1:

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

@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

The culprid seems to be https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6

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

@tiborvass any ideas?

@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.

@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.

@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.

@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

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.

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.

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.

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

@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 ;)

+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.

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

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

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

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.

@thocking: le assuming localhost is secure: please see https://github.com/docker/docker/issues/8898

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...

Similar issues here to those above including @jwthomp. I've spent a good 10+ hours trying to solve this problem and in the meantime have downgraded to docker 1.3.0.

I'm running the docker registry under Marathon and docker registry presently "supports SSL by running nginx as a frontend" (see https://github.com/docker/docker-registry/issues/697 ) but using nginx as a frontend is complicated by Marathon running the docker registry on various slave hosts/ports.

I could enable SSL directly within the registry (using GUNICORN_OPTS) but then it _only_ speaks SSL and can't pass the Marathon health checks.

I've modified the Bamboo HAProxy configuration system to also configure HAProxy as an https frontend to all services in the way that nginx would have been, but I still have problems with docker validating the certificate on my private registry, so that's still no go for me at this time.

It's all very well to protect against RCE but there also needs to be some backward compatibility. At least a flag for the docker daemon to specify all registries as insecure. There should be a way to specify http or https as part of the registry name in each docker pull command. At the moment, 1.3.1 seems like a big Catch-22 for anybody using a private registry.

@mhamrah https://github.com/boot2docker/boot2docker/pull/630

Nice.
On Fri, Nov 14, 2014 at 10:42 AM Ilya Radchenko [email protected]
wrote:

@mhamrah https://github.com/mhamrah boot2docker/boot2docker#630
https://github.com/boot2docker/boot2docker/pull/630

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8887#issuecomment-63082089.

@mhamrah I didn't have to do the removal of the ssh keys, etc. I just added the needed line in /var/lib/boot2docker/profile and restarted docker. Thanks for the tip!

Cool. I had trouble even ssh'ing in, I presume because of some version
mismatch between docker iso's. I actually switched to using vagrant +
coreos for docker support, and it works well. You just need to set
DOCKER_HOST, which boot2docker does automatically.

On Thu Nov 20 2014 at 1:52:21 AM Kayvan Sylvan [email protected]
wrote:

@mhamrah https://github.com/mhamrah I didn't have to do the removal of
the ssh keys, etc. I just added the needed line in
/var/lib/boot2docker/profile and restarted docker. Thanks for the tip!

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8887#issuecomment-63768043.

Sorry guys, I meant to respond earlier.

Like @ewindisch already said, we do not want to encourage this client-side behavior. The pain induced by requiring the flag as a daemon flag, is so that people actually set up TLS on their registry. Otherwise there's no incentive. Thanks for your understanding.

There is "an official" docker based image of the docker registry on the official docker registry. It's recommended use is without TLS.

If Docker would like users to setup TLS on their registry would it not make sense to balance the "pain induced" with an equal and opposite "pain reduction" by providing an official docker image that defaults to providing TLS?

@tiborvass . You are ignoring the internal behind-the-firewall dev case. So now I either have to set up a reverse proxy with SSL enabled in front of my registry (there is simply no reason to do this) or I have to go to each and every one of my developers and modify the arguments to the daemon running inside boot2docker. This makes no sense. There are many dev environments that provide configurable security in which the security is often disabled for dev environments. I'm surprised to see you close this issue when there have been so many votes for a solution.

What about whitelisting all private ips? Middle ground?

Or making the protocol name, 'http' or 'https' part of the image name for pull.

@tiborvass both @sroebuck and @blevine make great points. This will increasingly become the scenario for shops building containers in-house, and the fury over breaking the previous workflow will increase as well. We all understand the security side of this, and maybe pull isn't the right place to resolve it, but as long as the official registry image doesn't provide a simple, out of the box way to deal with this change, it should be considered a pretty important UX problem to be solved.

Hey @tiborvass ! This issue is biting us right now as well. I prefer @nickandrew's approach. Would be a bit more like git clone and also open up the possibility of different, pluggable protocols in the future. A win for docker since it would reduce coupling and a win for the community.

@blevine note that as of 1.3.2 localhost is whitelisted by default, see: https://github.com/docker/docker/pull/9124

You can make the registry listen on localhost by passing: -p 127.0.0.0:5000:5000 to docker run

@proppy, I'm not quite sure how listening on localhost helps me.

docker pull {http}myregistry.domain.com/myapp:latest

Or should it become an actual URL? I don't know anything about the registry protocol but it doesn't seem incompatible to extend the current syntax to specify a proper URL.

@blevine it means you can set up a local mirroring registry.

Arg, now I have to base64 decode my cloud-config for coreos to get my machines to start up

@tiborvass Wow, this is really unfortunate. :(

We have development clusters that we bring up and down on the fly and part of how we handle these clusters is we create a registry for that cluster. A cluster could be many physical nodes or vms, and it can also be on a developers desktop machine or laptop (though we typically can't launch a full stack). Each cluster is a fully self contained stack and development environment. We also have docker based command line tools that allow a developer to interact with any development cluster setup in the company.

In this sort of complex and dynamic environment, making TLS on a registry a requirement is gigantic pain. Having to modify the docker daemon startup every time we setup we add a new network that a registry could be on is equally a pain.

Don't get me wrong, I appreciate the thinking behind wanting to support TLS exclusively, however I encourage you to please consider that there are valid cases where the environment safely supports removing the complexity of TLS for the reduction in pain and infrastructure needed to support it.

@tiborvass +1. +1000. This has generated absolutely needless complexity for
us to a highly dynamic development workflow. The barrier to entry has been
raised significantly here for something that only needs to apply in a
production context. Please end our pain.

On Tuesday, December 9, 2014, Jeff Thompson [email protected]
wrote:

@tiborvass https://github.com/tiborvass Wow, this is one of those
virtual table flipping moments sadly. :(

We have development clusters that we bring up and down on the fly and part
of how we handle these clusters is we create a registry for that cluster. A
cluster could be many physical nodes or vms, and it can also be on a
developers desktop machine or laptop (though we typically can't launch a
full stack). Each cluster is a fully self contained stack and development
environment. We also have docker based command line tools that allow a
developer to interact with any development cluster setup in the company.

In this sort of complex and dynamic environment, making TLS on a registry
a requirement is gigantic pain. Having to modify the docker daemon startup
every time we setup we add a new network that a registry could be on is
equally a pain.

Don't get me wrong, I appreciate the thinking behind wanting to support
TLS, however there are cases where the environment safely supports removing
the complexity of TLS for the reduction in pain and infrastructure needed
to support it.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8887#issuecomment-66367681.

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

Doesn't --insecure-registry 0.0.0.0/8 solve your problem? That way you can still use HTTP.

This CIDR notation may be used more granularly to enable "behind the firewall" configurations by specifying ranges such as "--insecure-registry 172.16.0.0/12". I don't advise using this option at all, but I do recommend that users choosing this option to use a more selective range (such as their IP space) rather than all addresses as possible with 0.0.0.0/8.

The docker daemon is built into coreos, so I've got to somehow get those flags added to the startup across the cluster. I think it's much more flexible to have it on the pull command for environments where you cant control the docker daemon itself.

It's the equivalent of telling us to change a php.ini file for a shared php host.

On Dec 9, 2014, at 22:18, Tibor Vass [email protected] wrote:

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

Doesn't --insecure-registry 0.0.0.0/8 solve your problem? That way you can still use HTTP.

—
Reply to this email directly or view it on GitHub.

@mattwilliamson Execution flags are configurable with CoreOS. You may edit the systemd configuration file for Docker. For configuring this for a cluster, you may use cloud-config.

Examples of changing Docker configuration are on the CoreOS website. One could easily modify the instructions to add a debug-flag to specify an insecure-registry flag instead.

https://coreos.com/docs/launching-containers/building/customizing-docker/

@tiborvass the entire configuration ecosystem needs to support this to work easily out of the box. People are not expecting to make nonstandard customizations to the daemon startup everywhere they might be pulling (boot2docker, coreos, anything installed with the chef/puppet modules, etc) when they move to the step of setting up their own internal registry. The official registry container image itself _no longer works_ when using the steps marked "recommended" in the readme. The readme makes no mention of TLS whatsoever, in fact, and setting this up is a non-trivial process. In addition, as @mattwilliamson briefly mentioned above, there are myriad cases like shared build environments where a someone using the daemon to pull an image is not the same as the person configuring the daemon.

The bottom line is that making this a client-side argument is clearly the less disruptive solution, and more importantly, the less prescriptive solution. Docker has already become a primitive in dozens if not hundreds of other projects and workflows, and as such should really not be dictating usage patterns at this scope. Just because Git offers a simple runtime configuration option to disable http.sslverify doesn't mean Linus Torvalds encourages people to not secure their sensitive data in contexts where it is important to do so.

The git analogy is a good example of how this should work. Git doesn't force you to use TLS, and it's the user's decision when setting up a host what level they want to support. It's also the user's decision when pulling what level of security they require (or want to bypass). Configuration is a simple step, either globally or per repo. Although Docker doesn't force us to use TLS, by making the alternative non-trivial, it provides no other reasonable options.

The CIDR notation allows an arguably "heavy hammer" approach, and AFAIK, doesn't map to dns names, so even if I mask a 10.0.0.0/16, pulling some.private-registry.com in a 10.0/16 won't work. More importantly, configuration is not trivial.

Docker thrives in its simplicity for containerization, and greatly lowers the barrier for deploying applications in a variety of environments. We all know the benefits. Most developers can't answer simple CIDR notation questions, the docker config file may be in non-standard places (boot2docker and CoreOS locations are both different than other distros), and it's fairly easy to mess up these config files with difficult feedback loops for success. I have to tail syslog? Oh wait I'm on RHEL and it's messages?

A new developer can easily copy and paste a docker pull snippet, but having them ssh into a boot2docker host, run vi, edit a config file, then tail a syslog for errors... not so much. And oh yeah, you forgot to restart the docker daemon.

Here's what I'd like to see:

• Docker daemon settings applied via the docker command
• Docker pull settings for TLS overrides, specified via the docker command
• Docker pull settings preserved across commands for a specific registries

Yeah, but amazon doesnt allow you to change an autoscscale config. I will have to make a copy of it or make a whole new one.

On Dec 9, 2014, at 23:55, Eric Windisch [email protected] wrote:

Execution flags are configurable with CoreOS. You may edit the systemd configuration file for Docker. For configuring this for a cluster, you may use cloud-config.

Examples of changing Docker configuration are on the CoreOS website. One could easily modify the instructions to add a debug-flag to specify an insecure-registry flag instead.

https://coreos.com/docs/launching-containers/building/customizing-docker/

—
Reply to this email directly or view it on GitHub.

I currently have to work around this issue in my company's development environment by running this painstakingly researched command every time every time I do 'boot2docker up'

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 a pain. Adoption of docker inside my 400+ person company is stalled due to this issue. We have absolutely no use for TLS in our internal development environment where everything is controlled. We applaud its use for public hub repositories, and think forcing that elsewhere in all cases is a huge mistake.

@CleanCut very well put. Was really disappointed that 1.4.0 came and went and this issue remains open.

@CleanCut awesome - What I would like in boot2docker, is to have it add more information to the boot2docker init initial payload, which would then do this for you.

doesn't solve the non-vm-based-boot2docker specific problems, but --insecure-registry is not the only site specific customisation b2d users want.

can you make a pull request or issue for this in the boo2docker repo please?

Really raises the barrier for someone to use a project applauded for lowering barriers.

On Dec 13, 2014, at 02:10, Justin Clayton [email protected] wrote:

@CleanCut very well put. Was really disappointed that 1.4.0 came and went and this issue remains open.

—
Reply to this email directly or view it on GitHub.

@SvenDowideit Sure thing. Here it is

It sounds like there's consensus in this thread that this isn't a solved problem; could we please get this issue reopened?

Yes please!
Le 2014-12-15 15:05, "Justin Clayton" [email protected] a écrit :

It sounds like there's consensus in this thread that this isn't a solved
problem; could we please get this issue reopened?

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8887#issuecomment-67055878.

+1. I don't have anything to add, but want to simply vent my frustration over this decision. Like everyone else, I'm running a registry on a local network where security is handled ad nauseam elsewhere. I have dozens of docker containers running that now need to be bounced to add the 'well-documented' flag.

@bfirsh - this is one of those examples where a Docker daemon config file and a kill -HUP <dockerdaemonpid> would be awesome - trigger it to re-read the cfg, without needing to restart it - thus avoiding the container-restart

@SvenDowideit +1 for reload feature, it is really annoying to restart the server by simple configuration.

+1

Forgive me if I'm not understanding things correctly, but it seems like this issue is at the root of my own scenario (similar to the one outlined by @blevine where my company has a certificate-rewriting proxy that causes me to be unable to even talk to the public Docker Hub Registry). I know that eventually I will want to set up my own private registry, but I'm just at the learning phase, where I'm not sure yet whether I will be adopting Docker. This is a UX nightmare for someone in the early stages of adoption.

http://stackoverflow.com/questions/27536180/docker-on-mac-behind-proxy-that-changes-ssl-certificate

+1 to reopen this discussion, because looks like the community is not really happy with the current solution.

https://twitter.com/justinclayton42/status/550143834705780737

just trying to hit this from all angles until we hear a definitive answer on this topic.

+1, this is currently difficult to get configured and working.

@mhamrah makes great points. Don't force things, let users decide and configure for their own needs.

Registries that use self-signed certificates are also a problem, especially
in a developer context using boot2docker which switched to a read-only file
system. This requires an additional and different configuration step to
bootstrap the running vm.

I believe everyone that's posted to this thread sees the value and benefit
of docker, are using it daily, are trying to promote it in their
organizations, but are experiencing a painful and unnecessary issue that
hinders adoption.

As much as we all know docker it is still unknown to many people in tech-
especially within the enterprise. Documentation helps, but we are still
jumping through hoops, and it's a big blocker with a negative overall
effect.
On Sun, Jan 25, 2015 at 5:54 PM Jay Taylor [email protected] wrote:

+1, this is currently difficult to get configured and working.

@mhamrah https://github.com/mhamrah makes great points. Don't force
things, let user's decide and configure for their own needs.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8887#issuecomment-71398193.

+1 good for quickly trying out things

:+1:

:+1:

Super disappointing that we still can't pull from insecure registries without passing a flag to the docker daemon. This is just another hassle for every new machine we deploy.

+1

Some thoughts:

1. could we have hostname wildcards? e.g. --insecure-registry=*.internal
2. could self-signed certs be treated differently to http?
3. related to 2, could docker do something similar to SSH and prompt the user to accept a self-signed cert whenever it sees a new one/complain loudly if there's a mismatching one?

And while I'm making suggestions, why not treat localhost as always being secure? (as Chrome does)

Edit: ah, I see it already is.

+1000 on this.. and +1 on the configuration reload feature, that's what makes this twice as bad. I stayed with v1.2 because I figured surely a maintainer would realize how annoying the --insecure-registry flag on the daemon is for deployment and fix it, but somehow the minor releases keep ignoring it.

For example, if I had to change my private registry IP for whatever reason, I would have to restart every single docker daemon on every VM -- just because my registry changed!? Those 2 things should never be coupled that tightly. And telling people to just add 0.0.0.0/8 defeats the whole purpose of the security implementation in the first place.

Adding this flag to the push/pull commands seems so obvious as a fallback for the daemon flag, please someone explain to me why they are still fighting it but adding "nice to have" features in the meantime.

@agquick's comment is spot on, especially wrt "nice to have" features.

Realizing this is a continuing pain for a substantial number of users, we are reconsidering adding --insecure to pull. @ewindisch and I will be working on a PR that we'll link to this issue.

Apologies for the long wait, and thanks for voicing your opinions and pointing out your pain points.

@tiborvass I can imagine there's an equally large number of users that _don't_ want to allow pulls from insecure registries. I realise Docker currently doesn't have fine-grained control over permissions/config, but if there's a chance to be able to "lock" this down, I think that would be a nice touch.

Oh my make it so! Was about to implement it myself.

Sent from my BlackBerry 10 smartphone on the Bell network.
From: Sebastiaan van Stijn
Sent: Monday, February 23, 2015 4:53 PM
To: docker/docker
Reply To: docker/docker
Cc: Kristopher Cieplak
Subject: Re: [docker] --insecure-registry should be on "docker pull" (#8887)

@tiborvasshttps://github.com/tiborvass I can imagine there's an equally large number of users that don't want to allow pulls from insecure registries. I realise Docker currently doesn't have fine-grained control over permissions/config, but if there's a chance to be able to "lock" this down, I think that would be a nice touch.

—
Reply to this email directly or view it on GitHubhttps://github.com/docker/docker/issues/8887#issuecomment-75644600.

@thaJeztah I'm trying to figure out what use case you're thinking of that means we can't have a --insecure-registry flag to docker pull.

• if a user doesn't want to be accidentally MITMed on a secure registry, they can just avoid passing --insecure-registry
• if a user wants to enforce on users that all images come from secure registries (i.e. an 'enterprisey' scenario), they cannot actually enforce this at all at the moment anyway!

So could you elaborate on what docker pull --insecure-registry inhibits?

To elaborate on my second point, I can't see how you'd lock this down without rethinking a significant amount of how docker works! Putting aside being able to docker load a tarball you could obtain by writing your own registry puller, and using docker run -v to escalate privs and add something to the daemon arguments, there's a very simple way to bypass any 'enforcement':

$ docker pull registry:5000/aidanhs/blah                                    
FATA[0004] Error: v1 ping attempt failed with error: Get https://registry:5000/v1/_ping: EOF. If this private registry supports only HTTP or HTTPS [...]
$ socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 &
[1] 22924
$ docker pull localhost:5000/aidanhs/blah
Pulling repository localhost:5000/aidanhs/blah
[...]
Status: Image is up to date for localhost:5000/aidanhs/blah:latest
$ docker tag localhost:5000/aidanhs/blah registry:5000/aidanhs/blah

if a user wants to enforce on users that all images come from secure registries (i.e. an 'enterprisey' scenario), they cannot actually enforce this at all at the moment anyway!

This is the scenario, yes.

To elaborate on my second point, I can't see how you'd lock this down without rethinking a significant amount of how docker works

I fully understand that (at this moment) there's no way to lock it down. Users having access to docker.sock have effectively root access, so can change anything they like. Also, they would still be able to change the daemon flag and restart the daemon.

However, it _does_ give a clear signal to the user if docker pull --insecure-registry .. gives an error ("Insecure registries are disabled"), which _would_ notify users that it isn't desired, for example, when trying some example they found somewhere.

So, would it cover all cases? No. Would it _hurt_, I don't think so either.

I personally feel it'd do more harm than good, simply because it misleads people to think "oh look, docker enforces this" when actually it's a very superficial protection. I could go on, but in the end I think it comes down to a matter of taste.

If you're looking to how it might hurt, just scroll up. There are myriad UX issues with this approach that create barriers to adoption, and they're all detailed above. 

I view the issues mostly with docker unable to restart without killing sub
containers. that make configuring/reconfiguring it much harder.

On Wed, Apr 15, 2015 at 8:11 PM, Jan Krueger [email protected]
wrote:

+1

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8887#issuecomment-93362359.

I'm pretty disappointed that there hasn't been some action taken on this issue yet. It's obviously causing a number of people pain.

It's obviously annoying to a huge number of people, it's actively blocking my work right now. Having to restart the Docker daemon to allow pulling from an insecure registry ranges from annoying to downright impossible depending on the situation you're in.

The main argument for not doing this seems to be that the system administrator should be able to lock the system down and make sure that only images from secure repos can be pulled. That use case is definitely real but I think it makes a bad default. It seems a lot more reasonable to have a flag that can be passed to the daemon on start like --no-insecure which disables --insecure-registry usage in pull. That way an admin can lock things down if s/he really wants to.

For those highly desiring this behavior, I do offer the following workaround. I understand it will not be viable for all users as it does not use the Docker API for pulls. It is also somewhat slow...

See my project 'docker-pull': https://github.com/ewindisch/docker-pull

You would use it as such:

docker run ewindisch/docker-pull --insecure-registry 10.0.0.0/16 10.0.1.2/someimage | docker load

It's also possible to allow all registries as insecure:

docker run ewindisch/docker-pull --insecure 10.0.1.2/someimage | docker load

I'll remind that it is _still_ highly ill-advised to actually do this.

@ewindisch nifty hack.

Another pretty good solution is to use a tcp tunnel:

$ docker pull host:5000/image #fails
$ ssh -N -L 5000:host:5000 user@host
$ docker pull localhost:5000/image #works

These are both fantastic workarounds!

I too would like to see the default reversed.

On Apr 15, 2015, at 6:14 PM, Joe Doliner [email protected] wrote:

I'm pretty disappointed that there hasn't been some action taken on this issue yet. It's obviously causing a number of people pain.

It's obviously annoying to a huge number of people, it's actively blocking my work right now. Having to restart the Docker daemon to allow pulling from an insecure registry ranges from annoying to downright impossible depending on the situation you're in.

The main argument for not doing this seems to be that the system administrator should be able to lock the system down and make sure that only images from secure repos can be pulled. That use case is definitely real but I think it makes a bad default. It seems a lot more reasonable to have a flag that can be passed to the daemon on start like --no-insecure which disables --insecure-registry usage in pull. That way an admin can lock things down if s/he really wants to.

—
Reply to this email directly or view it on GitHub.

so this is reopened and the current status after 4 months is nothing and as a workaround use a bunch of hacks? :-/ Is there some discussion about this going on elsewhere or is it just dead?

And yes, +1

+1

+1

I would like to point out that I counted the instances of "+1" on this page, and the count comes to 31 so far. That's not counting the other supportive comments that don't actually include that exact string.

The issue here is that enabling --insecure on pull takes the control away from the sysadmin, where it belongs.
Security is hard, and making changes to loosen security is not a small decision.
Also, people that are perfectly happy with the current setup are not going to come on here and -1 this either.
On the other hand...
It is trivial to re-configure the daemon to enable insecure pulls from a registry.
It's also trivial to setup some self-signed certs and not even have to re-configure docker.

"Sysadmin" is one use-case for docker, but I "developer" and "non-sysadmin" are equally valid use cases. For a developer, providing an --insecure option reduces friction in the workflow.

Perhaps we could have the best of both worlds by providing an option that sysadmins could specify to _deny_ the usage of an --insecure option. That way, sysadmins still have full control, but non-sysadmin cases don't have to deal with the workflow pain.

What is trivial for a sysadmin can be surprisingly cumbersome for non-sysadmins. I've had to help nearly two dozen developers make (and re-make) this configuration change across 5 different OS's used in our development group. I actually maintain a script to automate the config change for our environments.

Our sysadmins will not currently set up self-signed certs for our registry, whether it's trivial to do or not.

Anyway, even if this doesn't change, eventually people will adapt to them. I suppose the pain I'm dealing with will all go away the next time our sysadmins do maintenance on the registry, because at that point we should be able to get actual SSL certificates installed. Perhaps that's the whole point. Make it easier to take the secure path than the insecure path going forward.

:+1: @CleanCut, and everyone else said it all. I only work with the developer case and reconfiguring the the docker daemon is just waste of time for us.

If you have access to the docker socket today, you _are_ a sysadmin. You're
root already, you have "docker load" and already have workarounds to do
insecure registry pulls. Adding the image option to the client would not be
any less secure than the status quo.

There is something, however, to be said about intentionally increasing the
friction for developers trying to do the wrong thing in other to entice
them into doing the right one.
On Jun 18, 2015 12:41 PM, "Brian Goff" [email protected] wrote:

The issue here is that enabling --insecure on pull takes the control away
from the sysadmin, where it belongs.
Security is hard, and making changes to loosen security is not a small
decision.
Also, people that are perfectly happy with the current setup are not going
to come on here and -1 this either.
On the other hand...
It is trivial to re-configure the daemon to enable insecure pulls from a
registry.
It's also trivial to setup some self-signed certs and not even have to
re-configure docker.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8887#issuecomment-113213172.

@ewindisch @tiborvass reading back, I see https://github.com/docker/docker/issues/8887#issuecomment-75638745;

Realizing this is a continuing pain for a substantial number of users, we are reconsidering adding --insecure to pull. @ewindisch and I will be working on a PR that we'll link to this issue.
Apologies for the long wait, and thanks for voicing your opinions and pointing out your pain points.

Is that still the current position? (I don't think a PR was created)

+1

This continues to bother and annoy me on a daily basis.

:( sad conehead.

--inscure makes complete sense from a developer POV. Its on the person implementing docker in their environment to make it secure.

+1

:+1:

_USER POLL_

_The best way to get notified when there are changes in this discussion is by clicking the Subscribe button in the top right._

The people listed below have appreciated your meaningfull discussion with a random +1:

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@mingfang
@djannot
@Frusty
@tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ryan-stateless
@jonathanvaughn
@gollawil
@ebartz
@maelp

+1

+1

+1

We use an internal registry in a closed network, adding this would make deployment easier for us.

+1

If this issue is still open by Halloween I think all the +1's should have a one year drown-in-our-docker-sorrows anniversary party.

+1 for the party of sorrow!

On Sep 14, 2015, at 1:32 PM, Gordon [email protected] wrote:

USER POLL

The best way to get notified when there are changes in this discussion is by clicking the Subscribe button in the top right.

The people listed below have appreciated your meaningfull discussion with a random +1:

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@mingfang
@djannot
@Frusty
@tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ryan-stateless
@jonathanvaughn
@gollawil
@ebartz
@maelp

—
Reply to this email directly or view it on GitHub.

+1

+1 for the party of sorrow

Dear owner of the bot that tells people to stop using "+1":
we use +1 to get it dealt with and there is not much more to be said.

+1

+1

There are a couple of workarounds, including using SSH tunnels -- but that requires ssh accounts on the registry host. The following workaround, does not need that.

Run the registry port forwarder, as follows:

docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder

And then pull or push images from your local registry:

docker pull localhost:5000/your-image
docker push localhost:5000/my-image

@rsmoorthy That is fantastic. Thank you for succinctly demonstrating the futility of this current restriction.

Docker, please re-include this particular battery.

+1

I have to say that forcefully encouraging security on the user has seriously swayed my thoughts on using docker. I understand completely that we can add the --insecure-registry flag to the daemon on start, and I won't get into all the reasons that doesn't work all the time, or can be impossible.

I have a question for the Docker developers, do you guys really think that you know what is best for the end user? I for one do not require SSL on my registries at all, because the network they run on is already fully encrypted. So why on earth would I encrypt encrypted traffic, is this really doing anything besides adding overhead and moving pieces to an already complex and massive system?

Also are there really use cases where people are using a private registry over the internet? What does one do about authentication in that sense? Couldn't one just pull an image down and then tear it apart? Instead of trying to intercept it en route to another computer?

TL;DR +1

+1

@Supernomad well said.

See it from docker's side: it is one issue that is better kept never officially implemented, but with a lot of possible workarounds to ease the pain. Some users screaming loudly is still less painful than the competition's marketing labeling docker as "insecure on purpose", and damaging its reputation forever.
Having said that, +1.

@tiborvass @ewindisch This issue is over a year old. It's been over 8 months since you said it was to be re-evaluated. Have you evaluated it? If so, what has been decided? Don't leave a brother hanging! :-)

Since this issue was initially opened and closed and reopened, the community has come up with numerous ways to fix this themselves, mainly to demonstrate the futility of this default setting:

• ssh -N -L 5000:host:5000 user@host && docker pull localhost:5000/lolsecurity
• socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 && docker pull localhost:5000/lolsecurity
• docker-machine create -d virtualbox --engine-insecure-registry 0.0.0.0/0 lolsecurity
• docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder && docker pull localhost:5000/lolsecurity

Not to mention CoreOS now ships with --insecure-registry 0.0.0.0/0 as the default. These examples clearly show that the idea that there are separation-of-concerns lines between the "sysadmin" and the "developer" is now largely arbitrary and spurious in 2015. In fact, the very idea of containers (of which Docker is their chief evangelist) has greatly accelerated this trend away from the traditional ops that still bothers to call anyone "sysadmin" in the first place.

Anyway, I'd love to see this get closed for good, one way or another.

+1

+1

+1

Why should I trust Docker Registry with my SSL private key?

For the other CoreOS users left out to dry by this meddling,
https://coreos.com/os/docs/latest/registry-authentication.html#using-a-registry-without-ssl-configured

@politician couldn't have said it better myself. It most definitely, seems like docker is just ignoring the fact that a large portion of their users are at the very least dissatisfied.

The fact is I am in the process of migrating completely away from docker and I couldn't be happier with the decision. I am currently using git and lxc and its not only hand down faster than docker it actually allows me to do what is best for my company and not what another company thinks, albeit completely and utterly incorrectly, is best for me.

I highly suggest taking a look at the alternatives which are honestly better than docker, such as rocket, raw lxc, qemu (not the same but still better) just to name a few.

I will be strongly suggesting this course of action to everyone I know that is considering containers from now on. At the very least until the people at docker realize they have no idea, and I stress _absolutely_ no idea, what is best for the end user in terms of security.

I gave up and bought a cheap dedicated SSL cert. The Docker CLI dependency on the CA system is just too stong - self-signed certificates are not just operational frustrating, they simply don't work.

• docker-machine deletes your ca.crt override between down/up
• none of your base images include the cert making tools like drone for CI impossible
• docker CLI uses a non-standard folder for certs, so that's just something else to remember.
• even if you do get it to work 18 hours later, you'll always have a nagging feeling that something else is broken

Bottom line: Docker inflicts a persistent on-going penalty to your ops team when attempting to use a self-signed cert.

This is all the more frustrating since curl -k has existed for eternity.

+1

It's pretty sad, that they don't give a damn about this. If some dev just want's to fiddle around with docker and host his own environment, normally you don't want to mess around with SSL certs and stuff. Additionally, if you have your own server at home that is nowhere near to be public, you simply don't need SSL.

@buehler you can add the --insecure-registry option to your daemon's settings, or to your daemon.json configuration file; then you only need to configure it once, and pull without having to specify the flag

Just an update from us: We've since stripped Registry out of our infrastructure and reverted back to using our custom fork of dogestry with Azure Blob storage support. We discovered that Docker Registry was duplicating layers and our machines were running out of disk space which resulted in outages. Registry turned out to be a time-wasting dead-end for us.

@buehler just to concretize @thaJeztah 's proposal, add this line to the configuration:

--insecure-registry 0.0.0.0/0

You will be able to access whatever registry you want. Works well for testing stuff.

@politician the duplication happens if the images are tagged with different repositories. The lack of deletion of blobs is a significantly bigger issue.

@thaJeztah if it's that easy to do, but 80% (admittedly arbitrary number) of users need to do it, then please just make it the default.

@justinclayton no; setting that option basically says "ignore any issue with secure communication to the registry", so allow man-in-the-middle attacks "out of the box", or even the daemon falling back to non-TLS "http://". Docker _does_ already set it as a default for registries in the 127.x.x.x range.

If you have a local registry and don't want to generate a certificate for it, adding a --insecure-registry to your daemon options takes less than a minute to do. It should be a deliberate action though, not something that is set by default.

@thaJeztah I understand your argument, but that can't just be the end of it. There is a significant gap in user experience for new developers as a result of this being on the daemon side. The _majority_ scenario where this is a pain is a new developer who follows the instructions on docker.com to download and run the Docker Toolbox installer on their Mac. Upon completion, they immediately try to run docker pull <internally-signed-registry>/foo and are greeted with an error. This is the true issue. Perhaps that means this issue should be renamed?

There are lots of other ways this could also be solved for; I'm sure the community and the company could agree on one of them:

• The current name of this issue is '--insecure-registry should be on "docker pull"'. As this issue is still open, I have to assume this option is still being considered.
• If a single-command solution to this was provided (and documented) that was simple for newbie users, that would solve for this.
• In our case, the registry _is_ secured. It uses a cert signed by our internal CA like everything else in our build environment. This is sufficient security. If the daemon somehow was able to honor MacOS's certificate store, that would make this headache go away as well.
• If they were prompted to add the cert or make this configuration to the docker-machine during the Toolbox install process, that would probably be ok too.

Please let the 70+ participants of this issue know what direction you plan on taking with this, or else please just close the issue so we're not left hanging. Thanks.

@thaJeztah
There is no way to add single --insecure-registry to daemon opts without restarting all running containers. That is one of the main problems. We can't reload configuration without restart (issue lasts from 2013), we can't pull images from other insecure registries without adding option to daemon and also restart. And nowadays we still don't have a clear roadmap of fixing that issue.

@apakhomov guess it could be added to the list of configuration changes that can be updated without restarting https://docs.docker.com/engine/reference/commandline/daemon/#configuration-reloading. Can you open a separate issue for that?

+1.

Some PaaS providers don't give access to the daemon and run a private network for the user (Jelastic for example).

is it possible to add multiple insecure registries to docker ?
something like --insecure-registry x.x.x.x:xxxx --insecure-registry z.z.z.z:zzzz

@kkorada --insecure-registry=0.0.0.0/0 will make Docker behave like before.

@kkorada yes, you can specify multiple registries (the flag is --insecure-registry=[] - square brackets indicate it can be specified multiple times).

Also for docker 1.12, we'll make this option configurable in the daemon.json configuration file, without restarting the daemon. See the open pull request here: https://github.com/docker/docker/pull/22337

thank you @mingfang and @thaJeztah

As @mhamrah and @justinclayton suggested, I would also recommend a solution using ssh in addition to TLS, similar to how Git allows access to a respository using both ssh and TLS. This might make use of the ssh workaround that @justinclayton listed.

Though I have no data to back up my claim, I'd guess that there are many more private registries running behind firewalls than there are registries running on the open Internet. In that case, ssh is easier to configure and as, if not more, secure than TLS.

Furthermore, after having fought for days with docker push and my local, private registry running inside an internal, sufficiently secure virtual machine (and more time struggling to create self-signed certificates), I've just come to really appreciate rkt --insecure-options=image,tls,http.

It's mad that this isn't a client setting. Obviously it shouldn't be on by default because that would encourage insecure practice. Putting the setting on the daemon however makes it very impractical for debugging purposes or in local development environments.

My current use case: running a development environment with docker compose. The environment needs a local docker registry. It is intended to run entirely on a local VM.

The docker way: explaining how to configure docker-machine to enable insecure registry on each developers machine, possibly requiring them to recreate their docker-machine if they've already got one or edit the config by hand.

The hacky solution: socat running in each container that needs to use the registry, redirecting to localhost.

Not exactly making things easy...

+1

Really a pity for --insecure not to be a client configuration!
That creates a lot of pain for us as well very similar to many of the explanations above.
Please set --insecure-registry=0.0.0.0/0 by default pr provide a way to pass it to the docker command as well as docker-compose configurations.

+1

+1

Is it time for the annual +1 Pity Party again?

On Dec 13, 2016, at 1:00 AM, 沙包妖梦 notifications@github.com wrote:

+1

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

If the images layers are signed, there is no need to use CA PKI for security. See also how apt/yum work. Furthermore, using SSL in a LAN makes little sense, and in a cloud environment it means you must provision - aside from the certificates themselves - for a good randomness source (see also: https://lukehinds.github.io/2015-03-03-Entropy-in-the-cloud/).

Long story short: if it's unnecessary, don't force it on users.

I just opened #29736 which is related.

+1, if having a client-side --insecure-registry flag is not an option, there should be a way to specify a trusted certificate to be used for docker pull and docker push. Not everyone has access to trust certificates on a OS-level, or access to play around with the Docker daemon.

Hosted CI servers (that are being used to build docker images and push to a private registry) are a great example of when you might not have that level of access.

+1

@ajhodges https://docs.docker.com/registry/insecure/#using-self-signed-certificates

@tiborvass
Only works if you have sudo access...

+1 good way to discourage devs from using docker

+1, i would like to see --insecure-registry for docker login too.

I don't even see this as a security issue, since you are consciously doing it. And if someone unauthorized got root access this won't provide any security either. What merit does this restriction actually have?

If you had bad intentions you could just upload your malicious docker image to the DockerHub, which is trusted.

+1 and frankly this boggles the mind

+1 to the pain train.

Plus F*cking One!

Is there a PR open for this?

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.

+1 as well...

+1

+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 !

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

bump 🤣

+1

+1

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.

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.

+1

:+1: +1

+1

+1

+1

+1

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 ^_^

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.

For SOC compliance the option must not be enabled.

+1

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

5.

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