如何缓解Docker容器中的权限升级，以保护主机FS
关于安全性的问题。 我想允许非root用户在集群上部署容器，我担心他们是否可以装载主机目录，然后升级到容器内的根特权。 我从下面的文章中收集，映射容器根用户到主机非root用户的function仍然在以太？ 文章本身似乎是相对较旧的，我很想知道这些function是如何开发的。
“最近Linux命名空间的改进将很快允许运行没有root权限的全function容器，这要归功于新的用户名空间，这里将详细介绍这一点，而且这将解决主机和guest之间共享文件系统造成的问题，用户命名空间允许容器（包括root用户）中的用户映射到主机系统中的其他用户。
因此，Docker的最终目标是实现两项额外的安全改进：
1）将容器的根用户映射到Docker主机的非root用户，以减轻容器到主机特权升级的影响;
2）允许Docker守护程序在没有root权限的情况下运行，并将需要这些权限的操作委托给审计良好的subprocess，每个subprocess都有自己的（非常有限的）范围：虚拟networking设置，文件系统pipe理等。
https://docs.docker.com/articles/security/ http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/
我从下面的文章中收集，映射容器根用户到主机非root用户的function仍然在以太？
“ 用户命名空间已经到达Docker！ ”（ Phil Estes ， ESTESP ）这篇文章说明它已经不在了！
它将在docker1.9 （2014年11月） 的实验分支中提供 。 PR 12648 。
用户映射被确认：
用户命名空间最重要的特性之一就是允许容器与主机系统有不同的uid和gid范围视图。
具体来说，一个进程（在我们的例子中，我们的容器内的进程）可以提供一组来自主机uid和gid空间的映射，以便当进程认为它正在运行为uid 0（通常称为“root”），它实际上可能是以uid 1000，或者10000甚至34934322运行的。这一切都取决于我们在用户名空间内创build进程时提供的映射。当然，从安全angular度来看，这应该很清楚，这是一个很好的特性，因为它允许我们的容器继续以root权限运行，但是在主机上没有任何root权限 。
请参阅“ 实验：用户命名空间支持 ”文档页面（适用于来自experimental.docker.com的实验docker版本 ）。
docker daemon --userns-remap=default
请注意，在启用实验性用户命名空间的情况下运行Docker守护程序（如与主机（ --pid=host ，– --net=host等）共享命名空间）或其他容器时，某些标准Dockerfunction当前不兼容。
该用户映射能力现在是每个守护进程，而不是每个容器 （这将需要一个Linux内核的演进，而不是在工作中）。 与主机共享名称空间（–pid = host，–net = host等）
最后：
由于需要通过提供的映射将Docker守护进程的本地caching中的层数据分离出来，所以一旦使用了带有用户命名空间的实验版本， graphics目录的根目录（默认是
/var/lib/docker）将会有一个与重新映射的根uid和gid相关的额外间接级别 。例如，如果我提供给
--userns-remap标志--userns-remap用户具有以ID10000开头的从属用户和组范围，则以该重新映射设置运行的所有映像和容器的graphics目录的根将驻留在/var/lib/docker/10000.10000。
如果您使用实验版本，但不提供用户名称空间重新映射，则当前内容将被迁移到/var/lib/docker/0.0以区分重新映射的图层内容。
2016年2月更新：
正如Phil E的评论所指出的那样
截至上个星期，Docker 1.10发布了， 用户命名空间被包括在内 。
一个简短的说明，因为从实验到主从gradle， 文档现在驻留在守护程序命令行参考页面 。
没那么多：
- 允许docker守护程序在主机系统上以非root用户身份运行
- 对容器内的主机和root拥有非超级用户权限