Description
I assign IPv6 addresses directly to my docker containers and don't want anything docker-related to be available on the host IPv6 address.
By default, docker-proxy listens on the host IPv6 address to deal with traffic coming in on exposed ports (each with a different process). I therefore added --userland-proxy=false to the dockerd systemd configuration.
It turns out that the main dockerd process now listens on the exposed ports instead. While I was not able to establish a connection on these ports (I tried an SSL connection on port 443, with no success), this is still a bug, as it exposes information on the host IPv6 address unnecessarily (nmap can tell that something is listening on these ports).
Furthermore, while I was not able to establish a connection on these ports (I tried an SSL connection on port 443, with no success), I was wondering a few things:
- Why does
dockerd listen on exposed ports when --userland-proxy=false is set?
- What sort of communication can be done with
dockerd through these ports? Is any form of remote control possible?
Steps to reproduce the issue:
- use a host with IPv6 address
- expose a port from a container
- set
--userland-proxy=false
Describe the results you received:
dockerd listening on exposed port on host IPv6 address
Describe the results you expected:
nothing listening on exposed port on host IPv6 address
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
Client:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 22:01:48 2016
OS/Arch: linux/amd64
Server:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 22:01:48 2016
OS/Arch: linux/amd64
Output of docker info:
Containers: 7
Running: 7
Paused: 0
Stopped: 0
Images: 166
Server Version: 1.12.3
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 151
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.4.0-47-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.736 GiB
Name: cluster.dev.desec.io
ID: BITY:LMNY:JHQD:64NW:DVT5:HUBG:BQAR:KMGI:UK53:7JUC:T7XI:YNQH
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
127.0.0.0/8
Description
I assign IPv6 addresses directly to my docker containers and don't want anything docker-related to be available on the host IPv6 address.
By default,
docker-proxylistens on the host IPv6 address to deal with traffic coming in on exposed ports (each with a different process). I therefore added--userland-proxy=falseto thedockerdsystemd configuration.It turns out that the main
dockerdprocess now listens on the exposed ports instead. While I was not able to establish a connection on these ports (I tried an SSL connection on port 443, with no success), this is still a bug, as it exposes information on the host IPv6 address unnecessarily (nmap can tell that something is listening on these ports).Furthermore, while I was not able to establish a connection on these ports (I tried an SSL connection on port 443, with no success), I was wondering a few things:
dockerdlisten on exposed ports when--userland-proxy=falseis set?dockerdthrough these ports? Is any form of remote control possible?Steps to reproduce the issue:
--userland-proxy=falseDescribe the results you received:
dockerdlistening on exposed port on host IPv6 addressDescribe the results you expected:
nothing listening on exposed port on host IPv6 address
Additional information you deem important (e.g. issue happens only occasionally):
Output of
docker version:Output of
docker info: