-
Notifications
You must be signed in to change notification settings - Fork 18.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sterner warnings and deprecation notice for unauthenticated tcp access #41285
Conversation
Needs deprecation period? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this is bad, but we need to look at how to deal with this (see my comment)
integration/container/daemon_test.go
Outdated
err := d.StartWithError("--host", "tcp://127.0.0.1:0") | ||
assert.Assert(t, err != nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've especially seen the "localhost" / 127.0.0.1 case being in use quite frequently (on Desktop). Should we follow the same rules as for "insecure registries", and
- have an exception for
127.0.0.0/8
- add a flag to allow the range to be customised?
I know all are bad, and insecure (containers can access, depending on their network settings, so can compromise the host) but also concerned that there's many "valid" (between big brackets) use-cases
@justincormack @tonistiigi @tiborvass any suggestions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we follow the same rules as for "insecure registries",
Exposing the API socket to other processes is more critical than "insecure registries".
I don't think the same rule should apply here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on Desktop
Do you mean Docker for Mac/Win? Or Linux desktop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exposing the API socket to other processes is more critical than "insecure registries". I don't think the same rule should apply here.
Yeah, so perhaps some explicit "I know what I'm doing" flag (as proposed in #37299)
Do you mean Docker for Mac/Win? Or Linux desktop?
At least Docker Desktop for Windows (some of that may be because (IIRC) in the past it didn't support named pipes, and defaulted to enabling the API on tcp as well)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can keep localhost (what about ipv6?) for now and phase it out later?
Another approach, we could generate TLS certs at a particular location for localhost and have the docker client automatically look for these certs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Linux, allowing localhost doesn't seem meaningful. If we are not sure about Windows, we can keep localhost on Windows for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another approach, we could generate TLS certs at a particular location for localhost and have the docker client automatically look for these certs.
Is it just like docker:dind image does? https://github.com/docker-library/docker/blob/master/19.03/dind/dockerd-entrypoint.sh#L21-L90
cmd/dockerd/daemon.go
Outdated
@@ -599,7 +599,7 @@ func loadListeners(cli *DaemonCli, serverConfig *apiserver.Config) ([]string, er | |||
|
|||
// It's a bad idea to bind to TCP without tlsverify. | |||
if proto == "tcp" && (serverConfig.TLSConfig == nil || serverConfig.TLSConfig.ClientAuth != tls.RequireAndVerifyClientCert) { | |||
logrus.Warn("[!] DON'T BIND ON ANY IP ADDRESS WITHOUT setting --tlsverify IF YOU DON'T KNOW WHAT YOU'RE DOING [!]") | |||
return nil, errors.New("Binding to IP address without --tlsverify is no longer supported") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have a deprecation process.
Disabling directly will cause some users to be unable to use it normally after the upgrade. (maybe they are not ready yet. of course, it is possible that most of these users use the default configuration unix domain socket)
And we have not notified when it will be officially disabled IIRC.
Plenty of valid reasons to do run raw tcp, even on |
I don't see the point of deprecation for this. I'm fine with adding a flag to allow this case through. The more verbose the better 😄 |
I agree with the sentiments already shared -- I use this in quite a few environments where it's not the best solution, but the security tradeoff is acceptable, so I'd definitely be sad if it were completely gone, but I'm perfectly happy with an explicit flag to enable it (even if said flag is really verbose like the proposed (I definitely don't want to see something like |
IIUC this would block image updates for idioms like jenkinsci/kubernetes-plugin#581. Could probably be adapted to use a Unix-domain socket via volume mount. |
IMO, best option would be automatically generated certificates and enabled TLS verify for TCP connections. Most people are too lazy to study how to generate certificates but most probably they are able copy certificate files to client if there instructions about it. And for those who really don't care about security there can be that super long and desribe switch available. |
f2f7ac4
to
4e7bd20
Compare
I have updated this as follows: Add flag Without this flag the daemon will sleep 30s for each unauthenticated I have special cased localhost (both v4 and v6 should be handled) to not sleep in this case... not sure if that's the best decision but 🤷♂️. Warnings are a bit more stern, including claiming that the flag will be required in the next release instead of having a sleep. |
4e7bd20
to
9f30f25
Compare
Looks like 2 tests need an update. |
78dfdad
to
688181d
Compare
Updated to fix tests. |
688181d
to
10f4843
Compare
7cafe7d
to
0790a51
Compare
Updated to have this work with |
0790a51
to
e532ae8
Compare
e532ae8
to
5a6e731
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just some quick comments/questions (didn't do a full review on my computer)
} | ||
|
||
if conf.TLSVerify == nil && conf.TLS != nil { | ||
conf.TLSVerify = conf.TLS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a change in behavior, correct? (automatically enable verify)
If so, I'm ok with that change, but we'll probably need to mention that explicitly in changelogs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is what we discussed on the PR review call.
@cpuguy83 two tests are failing;
|
60b0aa2
to
9d9dc1c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM if green 👍
Arf.. one more test failure @cpuguy83
|
Wrong branch. |
People keep doing this and getting pwned because they accidentally left it exposed to the internet. The warning about doing this has been there forever. This introduces a sleep after warning. To disable the extra sleep users must explicitly specify `--tls=false` or `--tlsverify=false` Warning also specifies this sleep will be removed in the next release where the flag will be required if running unauthenticated. Signed-off-by: Brian Goff <[email protected]>
9d9dc1c
to
5f5285a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
People keep doing this and getting pwned because they accidentally left
it exposed to the internet.
The warning about doing this has been there forever.
This introduces a sleep after warning.
To disable the extra sleep users must explicitly specify
--tls=false
or
--tlsverify=false
Warning also specifies this sleep will be removed in the next release
where the flag will be required if running unauthenticated.