Add --insecure to pull, push and login (carrying 10719)

[tiborvass]

Fixes #8887

Add --insecure to pull, push and login.

I carried @jsdir's work.

[jessfraz]

I'm not really comfortable with --insecure on login

[tiborvass]

Ping @ewindisch @NathanMcCauley

[dmp42]

cc @docker/distribution-maintainers

[endophage]

I agree with @jfrazelle re login. If somebody isn't willing to set up TLS to secure users' passwords on the network, they shouldn't be doing authentication.

[savar]

I disagree with @endophage and @jfrazelle. You try to enforce everybody to do it as you think it is right.

1. in terms of "MITM".. keep in mind that it seems to be quiet easy to get a valid certificate for somebody else (at least if you are one of the bad guy with enough money)
2. if you pull an image and runs it you're probably running in a "root" context which might be able to break out.. so it is almost much more worse to run an image which might be compromised than losing your credentials..

So in my opinion this topic was discussed a lot (I can remember 5 or 6 pull requests) and you still try to fight against this option which is in my case eyewashing.

Better add an option to enforce a fingerprint for a certificate.. this would even make it much easier to use TLS with a self signed certificate because everybody could specify it on a pull/push/login cmd...

[diogomonica]

@savar:

As far as your argument 1) goes, that is not true. There actually have been surprisingly few incidents over the past few years where attackers have been able to get in possession of certificates for domains they didn't own. If this was true, then no one should be doing online banking using browsers and TLS.

2. Is also not a good argument. There is a significant difference between an active MiTM and a passive sniffing attack. It is a lot harder for an attacker to setup a malicious Docker registry that intercepts legitimate requests and serves malicious images, than to simple sniff the credentials out of the air/wire.

Supporting --insecure on login is the wrong call.

[savar]

@diogomonica

2. it might be harder, but it would be not that hard to even wrap the container you're pulling from the original repository.. so this is not a good argument against my argument but I agree that it is much easier to upload "bad" images afterwards if you get the credentials...

but the RISK is more or less the same.. if I know about docker and I want to do something bad, even if I have no credentials I will hook up and send you a bad image.. maybe automatically wrapping the original image you wanted to pull..

so if you have --insecure on pull .. you shoulnd't care about --insecure on login..

3. if you have your private network which is fully in your control (company network..) it might be impossible to do a MITM but you still want to use TLS.. (even if it is then not really necessary/helpful)

4. the initial idea to force everybody to install the CA certificate into your system is also not 100% the right way.. in that case the company (or a bad admin) can really do the MITM because now the company can be google/microsoft/....

At the end it would be nicer if docker would have something like a local cert storage (like Firefox/Chrome/...) where you can install your certificate easily.. that would probably solve most of the issues.

[dmcgowan]

so if you have --insecure on pull .. you shoulnd't care about --insecure on login..

As soon as an --insecure login is allowed, now every --insecure pull will be transmitting credentials in the plaintext, this is what we are actively avoiding and something you should care about. If you don't care, then don't require credentials on the registry.

We are actively designing to improve this use case for the v2 registry, mostly involving easier ways to setup trust between a daemon and registry and avoid sending credentials every time. However we should not support making the existing use case less secure in the meantime. If you are passionate about trust/distribution related topics, I encourage you to head over the distribution project and get involved there https://github.com/docker/distribution.

[tiborvass]

@diogomonica @dmcgowan I'm fine removing login --insecure, would it be accepted if I did only pull --insecure and push --insecure ?

[dmcgowan]

I would prefer a check that the index is not official. I am not fan of additional special checks but it shouldn't be possible to overwrite a known secure endpoint on the client end.

[endophage]

I'm ok with pull and push supporting --insecure, but I also agree with @dmcgowan. It would be better if it indicates that an insecure registry is acceptable but should not force a fallback if the registry supports TLS.

[dmcgowan]

It will not force a fallback, the insecure flag will still prefer HTTPS, only allow fallback to HTTP

[stevvooe]

There really shouldn't be a short flag for insecure. If one wants this, please type it out.

[stevvooe]

@dmcgowan I'm wondering if the flag should be something like "--allow-http-fallback" or something more descriptive of what is actually happening.

[dmcgowan]

The --insecure flag matches the daemon side flag of --insecure-registries. Although it is just used for http fallback, it will likely be used in the future as an escape hatch for installing from untrusted registries as well (possibly any v1 registry). If you really want the flag to be more descriptive of what is happening, might I suggest --i-dont-want-to-properly-configure-my-daemon-or-registry.

[tiborvass]

@stevvooe @dmcgowan it's not only used for http fallback, it's also used for SkipVerify for HTTPS.

[xiaods]

not comfortable with this feature. do we indeed preder this flag --insecure?

[diogomonica]

My general feeling is that we should be pushing for a safer Docker ecosystem, and this "feature" being merged gets us further from this goal.

[ewindisch]

It's also worth noting that there are a variety of workarounds for this.

I'm not terribly comfortable with this, but it's also of the operator's choice to do something terrible and/or shoot themselves in the foot. Such discussions make me question if the engine should have a tainted flag as in the Linux kernel.

[tiborvass]

@ewindisch @diogomonica @NathanMcCauley if one of you could formulate a final decision on this, that would be very helpful. Make sure to take into account all the users' needs that were +1-ing all those closed PRs / issues. In the meantime, I'm closing this since it cannot be merged.