关于安全性的问题。我想允许非root用户在集群上部署容器,我担心他们是否可以挂载主机目录,然后升级到容器内的root权限。我从下面的文章中收集到,将容器root用户映射到host-non-root-user的功能仍然在以太网中?文章本身似乎相对较老,我很想知道这些功能是如何发展的。
" Linux名称空间的最新改进很快就会允许运行 由于新功能,没有root权限的全功能容器 用户命名空间这里详细介绍了这一点。而且,这会 解决主机和主机之间共享文件系统造成的问题 guest,因为用户命名空间允许用户在容器内 (包括root用户)要映射到主机中的其他用户 系统
因此,Docker的最终目标是实现另外两个目标 安全改进:
1)将容器的root用户映射到Docker的非root用户 host,以减轻容器到主机权限的影响 升级;
2)允许Docker守护程序在没有root权限的情况下运行 和委托需要这些特权的操作经过良好审核 子流程,每个流程都有自己的(非常有限的)范围:虚拟网络 设置,文件系统管理等。
https://docs.docker.com/articles/security/ http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/
答案 0 :(得分:2)
我从以下文章中了解到,将容器root用户映射到主机非root用户的功能仍然在以太网中?
文章“User namespaces have arrived in Docker!”(Phil Estes,ESTESP)说明它不再是ehter了!
它will be available in the experimental branch of docker 1.9(2014年11月)。 PR 12648
确认用户映射:
用户命名空间的最重要的功能之一是它允许容器具有与主机系统不同的uid和gid范围视图。
具体来说,进程(在我们的例子中,我们的容器内的进程)可以从主机uid和gid空间提供一组映射,这样当进程认为它以uid 0运行时(通常称为uid 0) “root
”),它实际上可能以uid 1000或10000,甚至34934322运行。这完全取决于我们在用户命名空间内创建进程时提供的映射。当然,应该很清楚,从安全角度来看,这是一个很棒的功能,因为它允许我们的容器继续以root权限运行,但实际上没有主机上的任何root权限。
有关详情,请参阅“Experimental: User namespace support”文档页面(适用于experimental docker build的experimental.docker.com)。
docker daemon --userns-remap=default
请注意,当运行启用了实验性用户命名空间的Docker守护程序时,某些标准Docker功能当前不兼容,例如与主机(--pid=host
,--net=host
等)或其他容器共享命名空间
用户映射能力现在是每个守护进程,而不是每个容器(这需要Linux内核演进,但不是)。 与主机共享命名空间(--pid = host, - network = host等)
最后:
由于需要通过提供的映射来隔离Docker守护程序的图层数据的本地缓存中的内容,因此一旦您使用具有用户名称空间的实验版本,图表目录的根目录(
/var/lib/docker
by默认情况下)将有一个额外的间接级别,它与重新映射的根uid和gid 相关。例如,如果我提供给
--userns-remap
标志的重新映射用户具有以ID10000
开头的从属用户和组范围,那么所有运行的图像和容器的图形目录的根目录重新映射设置将驻留在/var/lib/docker/10000.10000
如果您使用实验性构建但未提供用户名称空间重新映射,则您的当前内容将迁移到/var/lib/docker/0.0
,以将其与重新映射的图层内容区分开来。
2016年2月更新:
正如Phil E
的评论所述截至上周,Docker 1.10已发布, user namespaces was included as a feature 。 请注意,由于从实验到硕士毕业,documentation now resides in the daemon command-line reference page。
答案 1 :(得分:1)