隔离具有用户命名空间的容器

Linux 命名空间为正在运行的进程提供隔离，限制其访问添加到系统资源中，而正在运行的进程不知道这些限制。有关 Linux 命名空间的更多信息，请参阅 Linux 命名空间。

防止来自容器内部的权限提升攻击的最佳方法是将容器的应用程序配置为以非特权用户身份运行。为其进程必须作为rootuser 中，您可以将此用户重新映射到 Docker 主机上的低权限用户。映射的 user 被分配了一系列 UID，这些 UID 在命名空间中正常运行 UID 从 0 到 65536，但对主机本身没有权限。

关于重新映射和从属用户和组 ID

重新映射本身由两个文件处理：/etc/subuid和/etc/subgid. 每个文件的工作方式都相同，但一个文件与用户 ID 范围有关，而 other 替换为组 ID 范围。请考虑/etc/subuid:

testuser:231072:65536

这意味着testuser分配的从属用户 ID 范围231072以及接下来的 65536 个整数。UID231072映射到 namespace （在本例中为容器内）指定为 UID0 (root).UID231073映射为 UID1等。如果进程尝试提升权限在命名空间之外，进程作为非特权高号运行主机上的 UID，它甚至没有映射到真实用户。这意味着在 Host 系统上完全没有权限。

注意
可以为给定用户或组分配多个从属范围通过在/etc/subuid或/etc/subgid文件。在这种情况下，Docker 只使用第一个 5 个映射，根据内核只有 5 个条目的限制在/proc/self/uid_map和/proc/self/gid_map.

当您将 Docker 配置为使用userns-remap功能，您可以选择指定现有用户和/或组，或者您可以指定default.如果你指定default、用户和组dockremap为此而创建目的。

警告
某些分配不会自动将新组添加到/etc/subuid和/etc/subgid文件。如果是这样的话，您可能已经手动编辑这些文件并分配非重叠范围。此步骤为在先决条件中介绍。

范围不重叠非常重要，这样过程就无法获得访问。在大多数 Linux 发行版中，系统实用程序在添加或删除用户时管理范围。

这种重新映射对容器是透明的，但会引入一些容器需要访问 Docker 主机上的资源，例如将挂载绑定到文件系统的区域系统用户无法写入的从安全的角度来看，最好避免这些情况。

先决条件

从属 UID 和 GID 范围必须与现有用户关联。即使关联是实现细节。用户拥有在/var/lib/docker/.如果你没有想要使用现有用户，Docker 可以为您创建一个并使用该用户。如果要使用现有的用户名或用户 ID，它必须已经存在。通常，这意味着相关条目需要位于/etc/passwd和/etc/group，但如果您使用的是其他 authentication 后端，此要求可能会以不同的方式转换。
要验证这一点，请使用id命令：
$ id testuser uid=1001(testuser) gid=1001(testuser) groups=1001(testuser)
在主机上处理命名空间重新映射的方式是使用两个文件，即/etc/subuid和/etc/subgid.这些文件通常是托管的在添加或删除用户或组时自动，但在某些发行版，您可能需要手动管理这些文件。
每个文件都包含三个字段：用户的用户名或 ID，后跟开始的 UID 或 GID（在命名空间中被视为 UID 或 GID 0）以及用户可用的 UID 或 GID 的最大数量。例如给定以下条目：
```
testuser:231072:65536
```
这意味着由testuser是由主机 UID 拥有231072（看起来像 UID0在 namespace）通过 296607 （231072 + 65536 - 1）进行。这些范围不应重叠，来确保命名空间进程无法访问彼此的命名空间。
添加用户后，选中/etc/subuid和/etc/subgid以查看您的 user 在每个 URL 中都有一个条目。如果没有，您需要添加它，小心避免重叠。
如果要使用dockremap由 Docker 自动创建的 user，检查dockremap条目配置并重新启动 Docker。
如果 Docker 主机上有任何位置存在非特权用户需要写入，调整这些位置的权限因此。如果您想使用dockremap用户自动创建，但您无法修改权限，直到配置并重新启动 Docker 之后。
使userns-remap有效屏蔽现有镜像和容器层以及/var/lib/docker/.这是因为 Docker 需要调整这些资源的所有权，实际上将它们存储在/var/lib/docker/.最好启用此功能在新的 Docker 安装上，而不是现有安装上。
同样，如果您禁用userns-remap您无法访问任何启用时创建的资源。
检查对 user 的限制命名空间，以确保您的用例是可能的。

在守护程序上启用 userns-remap

您可以开始dockerd使用--userns-remap标记或遵循此使用daemon.json配置文件。这daemon.json方法。如果您使用该标志，请使用以下命令作为模型：

$ dockerd --userns-remap="testuser:testuser"

编辑/etc/docker/daemon.json.假设文件以前为空，以下条目启用userns-remap使用名为testuser.您可以按 ID 或名称对用户和组进行寻址。您只需要如果组名称或 ID 与用户名或 ID 不同，请指定组名称或 ID。如果您提供用户和组名称或 ID，用冒号分隔 (:）字符。以下格式都适用于该值，假设 UID 和 GIDtestuser是1001:
- testuser
- testuser:testuser
- 1001
- 1001:1001
- testuser:1001
- 1001:testuser
{ "userns-remap": "testuser" }
注意
要使用dockremapuser 并让 Docker 为您创建它，将值设置为default而不是testuser.
保存文件并重新启动 Docker。
如果您使用的是dockremap用户，请验证 Docker 是否使用这id命令。
$ id dockremap uid=112(dockremap) gid=116(dockremap) groups=116(dockremap)
验证该条目是否已添加到/etc/subuid和/etc/subgid:
$ grep dockremap /etc/subuid dockremap:231072:65536 $ grep dockremap /etc/subgid dockremap:231072:65536
如果这些条目不存在，请将文件编辑为rootuser 和分配一个起始 UID 和分配最高的 GID 加上 offset （在本例中为65536).请注意，不允许范围。
使用docker image ls命令。输出应为空。
从hello-world镜像。
$ docker run hello-world

验证中是否存在命名空间目录/var/lib/docker/叫替换为命名空间用户的 UID 和 GID，该 UID 和 GID 拥有，而不是 group-or-world-readable。一些子目录仍然是所有者root并具有不同的权限。

$ sudo ls -ld /var/lib/docker/231072.231072/

drwx------ 11 231072 231072 11 Jun 21 21:19 /var/lib/docker/231072.231072/

$ sudo ls -l /var/lib/docker/231072.231072/

total 14
drwx------ 5 231072 231072 5 Jun 21 21:19 aufs
drwx------ 3 231072 231072 3 Jun 21 21:21 containers
drwx------ 3 root   root   3 Jun 21 21:19 image
drwxr-x--- 3 root   root   3 Jun 21 21:19 network
drwx------ 4 root   root   4 Jun 21 21:19 plugins
drwx------ 2 root   root   2 Jun 21 21:19 swarm
drwx------ 2 231072 231072 2 Jun 21 21:21 tmp
drwx------ 2 root   root   2 Jun 21 21:19 trust
drwx------ 2 231072 231072 3 Jun 21 21:19 volumes

您的目录列表可能会有一些差异，尤其是当您使用与aufs.

将改用重新映射的用户所拥有的目录的/var/lib/docker/和未使用的版本（例如/var/lib/docker/tmp/在此处的示例中）可以删除。Docker 不使用它们，而userns-remap是启用。

禁用容器的命名空间重新映射

如果在守护进程上启用用户命名空间，则所有容器都使用用户命名空间。在某些情况下，例如特权 containers 时，您可能需要为特定容器禁用用户命名空间。有关其中一些限制，请参阅用户命名空间已知限制。

要禁用特定容器的用户命名空间，请添加--userns=hostflag 添加到docker container create,docker container run或docker container exec命令。

使用此标志时有一个副作用：不会为该容器启用用户重新映射，但由于只读（镜像）层在容器之间共享，因此容器文件系统的所有权仍将被重新映射。

这意味着整个容器文件系统将属于--userns-remap守护进程配置（231072在上面的示例中）。这可能会导致容器内的程序出现意外行为。例如sudo（检查其Binaries是否属于 user0）或带有setuid旗。

用户命名空间已知限制

以下标准 Docker 功能与运行 Docker 不兼容启用了用户命名空间的守护进程：

与主机共享 PID 或 NET 命名空间（--pid=host或--network=host).
不知道或无法使用的外部（卷或存储）驱动程序守护程序用户映射。
使用--privilegedmode 标志打开docker run而不指定--userns=host.

用户命名空间是一项高级功能，需要与其他能力。例如，如果卷是从主机挂载的，则文件所有权如果需要对卷内容的读或写访问权，则必须预先安排。

虽然用户命名空间容器进程中的 root 用户具有许多超级用户在容器（Linux 内核）中的预期权限根据内部知识施加限制，即这是一个用户命名空间过程。一个值得注意的限制是无法使用mknod命令。当运行时，在容器内创建设备的权限被拒绝这root用户。