Skip to content
This repository has been archived by the owner. It is now read-only.

containerd listens on port 10010 on public interface #2524

Closed
mimmus opened this issue Nov 9, 2018 · 5 comments
Closed

containerd listens on port 10010 on public interface #2524

mimmus opened this issue Nov 9, 2018 · 5 comments

Comments

@mimmus
Copy link

@mimmus mimmus commented Nov 9, 2018

Issue Report

On stable Container Linux release, 'containerd' service listens on port 10010 on public interface and cannot be modified/disabled.
This port could be used from other containers or abused from the network.

Bug

Related to this:
moby/moby#37507
containerd/containerd#2483 (comment)

Container Linux Version

Latest (1911) and previous (1855) stable Container Linux release.
As Docker version is the same, probably issue is present also on Beta and Alpha.

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1855.5.0
VERSION_ID=1855.5.0
BUILD_ID=2018-10-22-2305
PRETTY_NAME="Container Linux by CoreOS 1855.5.0 (Rhyolite)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

N/A

Expected Behavior

Service should be disabled or listen on localhost

Actual Behavior

Service listens on public IP and cannot be disabled

Reproduction Steps

  1. Fresh install of Container Linux
  2. Look at:
$ sudo netstat -anp | grep 10010
tcp        0      0 10.57.0.236:10010       0.0.0.0:*               LISTEN      871/containerd

Other Information

Bug should be fixed in Docker 18.06.1 but it is still present on Container Linux

@bgilbert
Copy link
Member

@bgilbert bgilbert commented Nov 16, 2018

Docker 18.06.1 fixed the problem by changing the way dockerd starts containerd. On Container Linux we launch containerd from a separate systemd unit, not from dockerd, which is why 18.06.1 didn't fix the problem on CL.

We're planning to fix this in simultaneous Container Linux alpha and beta releases early next week, and then in a stable release the following week if the change doesn't cause regressions in alpha or beta.

Thanks for reporting!

Loading

@mimmus
Copy link
Author

@mimmus mimmus commented Nov 17, 2018

Thanks for your consideration.
As a workaround (I need to wait for certification of my application stack before upgrading Container Linux), is there a containerd systemd unit that I can disable?

Loading

@dm0-
Copy link

@dm0- dm0- commented Nov 17, 2018

You could write the new config file somewhere, then write a containerd.service drop-in that overrides the environment variable CONTAINERD_CONFIG with its path.

Loading

@bgilbert
Copy link
Member

@bgilbert bgilbert commented Nov 19, 2018

This should be fixed in alpha 1967.0.0 and beta 1939.2.1, due shortly.

Loading

@bgilbert
Copy link
Member

@bgilbert bgilbert commented Nov 26, 2018

This should be fixed in stable 1911.4.0, due shortly. Thanks again for reporting.

Loading

@bgilbert bgilbert closed this Nov 26, 2018
dongsupark added a commit to flatcar-linux/coreos-overlay that referenced this issue Jun 26, 2019
In the past there had been an issue of containerd listening on a public
address with TCP port 10010. The issue was fixed in all channels, by
disabling the gRPC plugin of containerd. [1]  However, Flatcar edge
enabled the gRPC plugin again, to support cgroup v2 for containerd. [2]
As a result, the original issue of containerd happened again on Flatcar
edge.

To fix that, we should make containerd listen on localhost 127.0.0.1,
and a TCP port assigned dynamically. See also containerd/cri docs. [3]

[1] coreos/bugs#2524
[2] 8184af2
[3] https://github.com/containerd/cri/blob/53c2230ec09d3672dbfb39756954b1a4afdb1ab8/docs/config.md
dongsupark added a commit to flatcar-linux/coreos-overlay that referenced this issue Jun 26, 2019
In the past there had been an issue of containerd listening on a public
address with TCP port 10010. The issue was fixed in all channels, by
disabling the gRPC plugin of containerd. [1]  However, Flatcar edge
enabled the gRPC plugin again, to support cgroup v2 for containerd. [2]
As a result, the original issue of containerd happened again on Flatcar
edge.

To fix that, we should make containerd listen on localhost 127.0.0.1,
and a TCP port assigned dynamically. See also containerd/cri docs. [3]

[1] coreos/bugs#2524
[2] 8184af2
[3] https://github.com/containerd/cri/blob/53c2230ec09d3672dbfb39756954b1a4afdb1ab8/docs/config.md
dongsupark added a commit to flatcar-linux/coreos-overlay that referenced this issue Jun 26, 2019
In the past there had been an issue of containerd listening on a public
address with TCP port 10010. The issue was fixed in all channels, by
disabling the gRPC plugin of containerd. [1]  However, Flatcar edge
enabled the gRPC plugin again, to support cgroup v2 for containerd. [2]
As a result, the original issue of containerd happened again on Flatcar
edge.

To fix that, we should make containerd listen on localhost 127.0.0.1,
and a TCP port assigned dynamically. See also containerd/cri docs. [3]
Also bump containerd to 1.1.2-r3.

[1] coreos/bugs#2524
[2] 8184af2
[3] https://github.com/containerd/cri/blob/53c2230ec09d3672dbfb39756954b1a4afdb1ab8/docs/config.md
dongsupark added a commit to flatcar-linux/coreos-overlay that referenced this issue Jun 27, 2019
In the past there had been an issue of containerd listening on a public
address with TCP port 10010. The issue was fixed in all channels, by
disabling the gRPC plugin of containerd. [1]  However, Flatcar edge
enabled the gRPC plugin again, to support cgroup v2 for containerd. [2]
As a result, the original issue of containerd happened again on Flatcar
edge.

To fix that, we should make containerd listen on localhost 127.0.0.1,
and a TCP port 10010. See also containerd/cri docs. [3]
Also bump containerd to 1.1.2-r3.

[1] coreos/bugs#2524
[2] 8184af2
[3] https://github.com/containerd/cri/blob/53c2230ec09d3672dbfb39756954b1a4afdb1ab8/docs/config.md
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants