Docker root访问主机系统
当我以普通用户的身份运行容器时，我可以在主机文件系统上映射和修改由root拥有的目录。 这似乎是一个很大的安全漏洞。 例如，我可以执行以下操作：
$ docker run -it --rm -v /bin:/tmp/a debian root@14da9657acc7:/# cd /tmp/a root@f2547c755c14:/tmp/a# mv df df.orig root@f2547c755c14:/tmp/a# cp ls df root@f2547c755c14:/tmp/a# exit 现在，我的主机文件系统将在键入df （主要是无害的示例）时执行ls命令。 我不能相信这是所期望的行为，但它发生在我的系统（debian stretch）。 docker命令具有正常的权限（755，不是setuid）。
我错过了什么？
也许再澄清一点很好。 我现在不想对容器本身做什么或者做什么感兴趣，也不关心容器内的根访问。
相反，我注意到我的系统上的任何人都可以运行docker容器，可以使用它来获得对我的主机系统的root访问权限，并以root身份进行读写操作：有效地授予所有用户root访问权限。 这显然不是我想要的。 如何防止这一点？
有许多Docker安全function可用于帮助Docker安全问题。 特定的将帮助你的是用户命名空间。
基本上你需要事先停止Docker守护进程，在主机上启用User Namespaces：
dockerd --userns-remap=default &
注意，这将禁止容器在特权模式下运行（从安全angular度来看，这是一件好事），并重新启动Docker守护进程（在执行此命令之前应该停止它）。 当你进入Docker容器时，你可以限制它到当前的非特权用户：
docker run -it --rm -v /bin:/tmp/a --user UID:GID debian
无论如何，尝试使用默认命令进入Docker容器
docker run -it --rm -v /bin:/tmp/a debian
如果您尝试操作映射到Docker卷（在本例中为/bin ）的主机文件系统，那么文件和目录归root所有，那么您将收到Permission denied错误。 这certificate用户命名空间提供了您正在寻找的安全function。
我build议通过https://github.com/docker/labs/tree/master/security/userns上的此安全function通过Docker实验室。 我已经完成了所有的实验室，并在那里开设了问题和公关，以确保实验室的完整性，并为其担保。
在主机上运行docker命令的权限可以访问该主机上的root。 这是该工具的devise，因为安装文件系统和隔离应用程序的function需要Linux上的rootfunction。 这里的安全漏洞是任何授予用户访问权限的系统pipe理员，以便运行他们不会信任的主机上的root访问权限的docker命令。 因此，将用户添加到docker组应该小心。
如果使用正确的话，我仍然将Docker视为安全性改进，因为在容器内运行的应用程序受限于对主机可以执行的操作。 导致损坏的能力是由运行容器的明确选项给出的，例如将根文件系统挂载为rw卷，直接访问设备，或向root添加允许转义命名空间的function。 除了显式创build这些安全漏洞外，在容器内运行的应用程序比在容器外运行的应用程序访问要less得多。
如果您仍想尝试locking可以访问Docker的用户，还有一些额外的安全function。 用户命名空间是阻止容器内部的root用户在主机上拥有root访问权限的用户之一。 还有互锁 ，可以限制每个用户可用的命令。
你错过了默认情况下，容器内部运行为内部0。 所以这是预料之中的。 如果你想限制容器内部的权限，可以在Dockerfile中用USER语句构build它。 这将在运行时设置给指定的用户，而不是以root身份运行。
请注意，这个用户的uid不一定是可预测的，因为它被分配在你构build的图像中，并且不一定映射到外部系统上的任何东西。 但重点是，它不会是根。
有关更多信息，请参阅Dockerfile参考 。