Deprecate Docker API over TCP without TLS

[justincormack]

Running the Docker socket over TCP without any authentication, even on localhost (yes, JavaScript can connect to localhost from your browser) is very dangerous, even in non production environments. Since we have had named pipe support for Windows for some years now, and always have had unix socket support, there is no reason for this to be supported out of the box, and we should remove it. Obviously we will continue to support tcp with TLS.

If users really want to do this, they can make a proxy from tcp to the socket, which is pretty trivial, but then it is clearly their responsibility.

We could potentially have quite a long deprecation period, and should have warnings on the client and server.

[AkihiroSuda]

SGTM but maybe except DIND?

[justincormack]

@AkihiroSuda why do you need it in dind?

[AkihiroSuda]

a nondind container may want to connect to a dind container.
I think non-tls is allowed when separate nw is created.

[justincormack]

The problem is that Docker cannot know if there is a separate network. We could have a flag to allow the current behaviour still, but I would still rather you had to run a proxy. The dind container could include a suitable proxy option I guess.

[justincormack]

We could add a feature to generate a TLS keypair for simple local use cases.

[AkihiroSuda]

Yes, I think just including socat is fine (after some deprecation period of the current behaviour)

[AkihiroSuda]

Still SGTM

[cyli]

It sounds like from the description the comments in from the comments from #37299, this feature for deprecating support for tcp without mutual TLS, as opposed to unauthenticated one-way TLS. If that's the case, would it make sense to clarify on the issue title?

[corhere]

#41285 (comment)

• future release; enable both --tls and --tlsverify by default: if a user didn't specify options, the daemon will fail to start as no certs are provided
• add options to explicitly disable tls / tlfverify: --disable-tls, --disable-tls-verify (name can be discussed)

[corhere]

An entry needs to be added to the deprecation log before we can enable --tlsverify by default.

[neersighted]

Now that we're getting serious about doing this (refer to #47556), paging @tianon for thoughts on what to do for docker:dind. Whatever we do there, we'll probably want to replicate for our dev container (I make use of the TCP API a fair bit for testing, at least).

[tianon]

We've had the docker:dind image doing automatic generation of all the necessary self-signed certificates for a while now, with honestly pretty limited success.

(For details, see the insanely hairy mess that is https://github.com/docker-library/docker/blob/1b4d76a2e8049074e723b5b8ecec417b1450a065/dockerd-entrypoint.sh -- generating the certs correctly/acceptably/securely in the first place is way harder than it ought to be IMO, but we also have to be careful not to clobber certificates a user might provide)

One of the biggest sets of users that complains any time anything breaks in that image is GitLab, and last I knew it was kind of complicated for them to set up certificates correctly for this to work for their pipelines. I don't know whether that's changed, but I suspect it's still complicated because they (GitLab) don't directly control how users include this in their YAML, and many of their users have copy-pasted some boilerplate, and that's the main source of the consternation any time anything changes (like the recent xtables vs nftables snafu).

See docker-library/docker#430 for a currently-active example of a contributor/user who is pretty frustrated about this.

IMO, turning the current delay into an error is OK if we have an escape hatch for users to say "yes, I accept the risk, please be really insecure", but I don't personally think --tls=false --tlsverify=false really conveys the severity of how insecure this configuration is appropriately. 😞

[PeterFeicht]

I just came across the deprecation warning and I'm not entirely sure if there will or will not be a way to override this. Can someone clarify that please?

I'm using Docker on Windows by running the Docker daemon in a WSL 2 instance and connecting to it with the docker executable running in Windows. (To clarify, I'm talking about Linux containers running in a Linux VM, not Windows containers.) Because there is no remote access to the Windows machine, the daemon is not exposed at all in that setup.

I would very much appreciate not having to mess around with encryption for such a use case.