如何缓解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拥有非超级用户权限