如何使用 --uidmap/gidmap 和 --net-host 选项正确运行具有 containerd ctr 的容器

编程问答 2022-05-22

问题描述

我正在运行一个带有 ctr 的容器，在使用用户命名空间将容器内的用户 (root) 映射到主机上的另一个用户之后，我想让主机网络可用于容器。为此，我使用了 --net-host 选项。基于一个非常简单的测试容器

$ cat Dockerfile
FROM alpine
ENTRYPOINT ["/bin/sh"]

我试试

sudo ctr run -rm --uidmap "0:1000:999" --gidmap "0:1000:999" --net-host docker.io/library/test:latest test

这给了我以下错误

ctr: OCI runtime create Failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"sysfs\\\" to rootfs \\\"/run/containerd/io.containerd.runtime.v2.task/default/test/rootfs\\\" at \\\"/sys\\\" caused \\\"operation not permitted\\\"\"": unkNown

如果我要么一切正常

  1. 移除 --net-host 标志或
  2. 删除 --uidmap/--gidmap 参数

我尝试将主机为 uid=1000 的用户添加到 netdev 组，但仍然出现相同的错误。 我可能需要使用网络命名空间吗？

编辑：

同时发现这是 runc 中的问题。如果我通过将以下内容添加到 config.json

来使用用户命名空间 
    "linux": {
        "uidMappings": [
            {
                "containerID": 0,"hostID": 1000,"size": 999
            }
        ],"gidMappings": [
            {
                "containerID": 0,

另外不要使用网络命名空间，这意味着省略条目

            {
                "type": "network"
            },

在 "namespaces" 部分，我从 runc 收到以下错误：

$ sudo runc run test
WARN[0000] exit status 1
ERRO[0000] container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"sysfs\\\" to rootfs \\\"/vagrant/test/rootfs\\\" at \\\"/sys\\\" caused \\\"operation not permitted\\\"\""
container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"sysfs\\\" to rootfs \\\"/vagrant/test/rootfs\\\" at \\\"/sys\\\" caused \\\"operation not permitted\\\"\""

解决方法

终于从this issue in runc那里找到了答案。它基本上是内核中的一个限制，即不拥有网络命名空间的用户不具有 CAP_SYS_ADMIN 能力，否则无法安装 sysfs。由于容器中的 root 用户映射到的主机上的用户没有创建主机网络命名空间，所以它没有 CAP_SYS_ADMIN。

根据 the runc issue 中的讨论，我现在确实看到以下选项：

  1. 删除 sysfs 的安装。

    在 config.json 使用的 runc 中，删除 "mounts" 中的以下部分：

            {
        "destination": "/sys","type": "sysfs","source": "sysfs","options": [
            "nosuid","noexec","nodev","ro"
        ]
    },

    就我而言，我也无法挂载 /etc/resolv.conf。通过删除这 2 个，容器确实运行良好并且可以访问主机网络。不过这不适用于 ctr。

  2. 设置一个从主机网络命名空间到容器网络空间（see here 和 slirp4netns）的桥。

  3. 如果可能，使用 docker 或 podman 似乎为此目的使用 slirp4netns。还有 an old moby issue 可能也很有趣。

containerdcontainerslinux-namespacesrunc