☰

为什么 Docker 在启动新容器时默认使用相同的用户和 cgroup 命名空间？

tag-icon • tag-icon linux docker debian
为什么 Docker 在启动新容器时默认使用相同的用户和 cgroup 命名空间？

为什么 Docker 在启动新容器时默认使用相同的用户和 cgroup 命名空间？

我不明白为什么 Docker 不设置新的用户命名空间，以便容器中的命名空间与主机上的命名root空间不一样。root

特别是，由于其他所有内容都是命名空间（cgroup 除外），因此默认情况下不完全隔离容器实际上是没有意义的。

有人可以解释为什么 Docker 默认不启用用户命名空间吗？

主机命名空间：

parallels@debian-gnu-linux-vm:~$ ls -la /proc/self/ns
total 0
dr-x--x--x 2 parallels parallels 0 Jan 30 17:29 .
dr-xr-xr-x 9 parallels parallels 0 Jan 30 17:29 ..
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 mnt -> mnt:[4026531840]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 net -> net:[4026531957]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 pid -> pid:[4026531836]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 user -> user:[4026531837]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 uts -> uts:[4026531838]

容器命名空间：

docker run -ti --rm debian:latest
root@210189a7a164:/# ls -la /proc/self/ns
total 0
dr-x--x--x 2 root root 0 Jan 30 16:30 .
dr-xr-xr-x 9 root root 0 Jan 30 16:30 ..
lrwxrwxrwx 1 root root 0 Jan 30 16:30 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 ipc -> 'ipc:[4026532287]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 mnt -> 'mnt:[4026532285]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 net -> 'net:[4026532290]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 pid -> 'pid:[4026532288]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 uts -> 'uts:[4026532286]'

主机和容器的user和cgroup命名空间是相同的。

答案1

至于 Docker 决定不默认启用用户模式的具体细节，您可能需要询问 Docker，但我可以提供一个可能的理由。

Docker 的总体设计理念似乎是实现容器的使用同时尽量减少开发工作流程的中断和复杂性。

启用用户命名空间可能会导致从底层主机挂载卷时出现文件/目录权限问题，因为容器中使用的 uid/gid 可能没有挂载目录的权限。

当然，可以通过仔细管理这些权限来解决此问题，但这会造成干扰。

用户命名空间可作为选项使用，因此各个组织和用户仍然可以启用它，只需进行设置即可。

值得注意的是，Docker 还在努力实现“无根”Docker 支持，目前这是一个实验性的选项（更多详细信息这里），这样可以解决整体问题，确保没有容器（或守护进程本身）以 root 身份运行。

答案2

这基本上是可用性和安全性之间的经典权衡。我为我的开发人员桌面配置了它，之后CVE-2019-5736据报道，用户命名空间可以缓解此问题，并在几个月后将其关闭。这使得使用主机卷变得非常困难。对于已部署的云原生应用程序来说，这不是什么大问题，但如果您使用 docker 进行开发运维，例如 CI 构建或系统管理员工具，或者用于依赖大量主机文件的旧版应用程序，那么问题就很大了。

使问题更加复杂的是，只有我一个人遇到了这个问题，如果用户命名空间像你建议的那样是默认的，当然就不会出现这种情况，但是这个功能直到 docker 1.10 才可用，到那时，更改默认值会对现有用户造成太大的干扰。

相关内容