Merge pull request #19587 from dvdksn/warn-exposed-daemon

engine: warn more about insecure daemon configurations / deprecate non-tls tcp

content/config/daemon/remote-access.md

@@ -8,32 +8,31 @@ title: Configure remote access for Docker daemon
 ---
 
 By default, the Docker daemon listens for connections on a Unix socket to accept
-requests from local clients. It's possible to allow Docker to accept requests
-from remote hosts by configuring it to listen on an IP address and port as well
-as the Unix socket. For more detailed information on this configuration option,
-refer to the
-[dockerd CLI reference](/reference/cli/dockerd/#bind-docker-to-another-hostport-or-a-unix-socket).
+requests from local clients. You can configure Docker to accept requests
+from remote clients by configuring it to listen on an IP address and port as well
+as the Unix socket.
 
 <!-- prettier-ignore -->
 > **Warning**
 >
-> Before configuring Docker to accept connections from remote hosts it's
-> critically important that you understand the security implications of opening
-> Docker to the network. If steps aren't taken to secure the connection, it's
-> possible for remote non-root users to gain root access on the host. For more
-> information on how to use TLS certificates to secure this connection, check
+> Configuring Docker to accept connections from remote clients can leave you
+> vulnerable to unauthorized access to the host and other attacks.
+>
+> It's critically important that you understand the security implications of opening Docker to the network.
+> If steps aren't taken to secure the connection, it's possible for remote non-root users to gain root access on the host.
+>
+> Remote access without TLS is **not recommended**, and will require explicit opt-in in a future release.
+> For more information on how to use TLS certificates to secure this connection, see
 > [Protect the Docker daemon socket](../../engine/security/protect-access.md).
 { .warning }
 
-You can configure Docker to accept remote connections. This can be done using
-the `docker.service` systemd unit file for Linux distributions using systemd. Or
-you can use the `daemon.json` file, if your distribution doesn't use systemd.
+## Enable remote access
 
-> systemd vs `daemon.json`
->
-> Configuring Docker to listen for connections using both the systemd unit file
-> and the `daemon.json` file causes a conflict that prevents Docker from
-> starting.
+You can enable remote access to the daemon either using a `docker.service` systemd unit file for Linux distributions using systemd.
+Or you can use the `daemon.json` file, if your distribution doesn't use systemd.
+
+Configuring Docker to listen for connections using both the systemd unit file
+and the `daemon.json` file causes a conflict that prevents Docker from starting.
 
 ### Configuring remote access with systemd unit file
 
@@ -88,3 +87,8 @@ you can use the `daemon.json` file, if your distribution doesn't use systemd.
    $ sudo netstat -lntp | grep dockerd
    tcp        0      0 127.0.0.1:2375          0.0.0.0:*               LISTEN      3758/dockerd
    ```
+
+## Additional information
+
+For more detailed information on configuration options for remote access to the daemon, refer to the
+[dockerd CLI reference](/reference/cli/dockerd/#bind-docker-to-another-hostport-or-a-unix-socket).

content/engine/security/_index.md

@@ -103,20 +103,22 @@ arbitrary containers.
 
 For this reason, the REST API endpoint (used by the Docker CLI to
 communicate with the Docker daemon) changed in Docker 0.5.2, and now
-uses a UNIX socket instead of a TCP socket bound on 127.0.0.1 (the
+uses a Unix socket instead of a TCP socket bound on 127.0.0.1 (the
 latter being prone to cross-site request forgery attacks if you happen to run
 Docker directly on your local machine, outside of a VM). You can then
-use traditional UNIX permission checks to limit access to the control
+use traditional Unix permission checks to limit access to the control
 socket.
 
 You can also expose the REST API over HTTP if you explicitly decide to do so.
-However, if you do that, be aware of the above mentioned security
-implications.
+However, if you do that, be aware of the above mentioned security implications.
 Note that even if you have a firewall to limit accesses to the REST API 
 endpoint from other hosts in the network, the endpoint can be still accessible
 from containers, and it can easily result in the privilege escalation.
 Therefore it is *mandatory* to secure API endpoints with 
 [HTTPS and certificates](protect-access.md).
+Exposing the daemon API over HTTP without TLS is not permitted,
+and such a configuration causes the daemon to fail early on startup, see
+[Unauthenticated TCP connections](../deprecated.md#unauthenticated-tcp-connections).
 It is also recommended to ensure that it is reachable only from a trusted
 network or VPN.