以 root 身份运行的 docker 守护进程带来的风险

信息安全 码头工人
2021-08-16 16:21:01

我的团队对使用 docker 感到非常兴奋,因为它有望简化我们的部署并提供许多其他设计和运营优势。我们最近开始真正开始使用它,并遇到了一些问题,因为 docker 守护进程以 root 身份运行。

一般来说,我对以 root 身份运行服务器平台的立场是“不要”。我们最近经历了一系列斗争,以让我们的运营商停止这样做,甚至停止在可以修改服务器部署的帐户下运行东西。所以马上,我有一个问题,回到这些人并要求他们设置 docker 以 root 身份运行似乎有点虚伪。

我不是第一个评论以 root 身份运行的 docker 守护进程所带来的风险的人。根据这个“最终,预计 Docker 守护进程将运行受限权限,......”我们是否应该等待这个问题得到解决?我认为 docker 会改善我们的安全配置文件,但这似乎使情况变得更糟。我对 docker 的热情已经消退,我不确定我是否有动力向我们的风险团队提出在这种状态下使用它的理由。

编辑:我应该澄清一下,我在这里并不特别关心用户是“docker”组成员的问题。了解这一点很重要,但这是可以管理的。我真的很感谢这里所有的好答案(赞成和反对)。我想我一直在将守护进程与容器本身混为一谈。我可能需要研究一个清晰的 docker 架构心智模型。这里到处都是很多很棒的东西。在接受答案之前,我将不得不思考一下。

我认为这是 docker 的一个主要缺陷是错误的吗?

3个回答

docker 守护进程确实以 root 身份运行,因为它以非常基本的方式与主机操作系统交互,但这与大多数/任何使用需要该特权的 linux 功能的系统守护进程没有什么不同。

这并不意味着使用 docker 是不安全的,只是你需要小心使用它。幸运的是,Docker 本身已经提供了一些相当不错的安全配置建议,并且以 Internet 安全中心的安全配置“最佳实践”指南的形式提供

运行 docker 时需要注意的几个实际注意事项。

首先,如果某人是主机上“docker”组的成员,他们实际上是系统上的 root,因为在这种情况下可以使用 docker 来提升权限。因此,您需要谨慎对待生产主机上该组的成员身份。

Docker 使用 Linux 功能来限制容器内的用户可以执行的操作,因此仅仅成为容器内的 root 并不一定意味着主机上的自动 root。也就是说,您确实需要小心诸如卷挂载之类的事情(例如,如果您将系统目录从主机挂载到容器中),因为这可能允许容器内的 root 用户更改主机上的文件。

您还可以相当轻松地减少提供给容器的功能,这可以进一步提高流程的安全性。

还请记住,您不需要以 root 身份在容器中运行进程,您可以通过一些配置以其他用户身份运行,这可以降低卷安装风险。

我发现考虑容器的方式是作为主机上的进程。如果您将在容器中运行的东西与直接在主机上运行它们进行比较,我会说容器架构可能会增加安全性而不是删除它,因为您在进程和主机之间有一个更好定义的接口等等控制进程可以在主机上执行的操作。

同样,更丰富的用户映射架构很快就会出现在 docker(计划在 1.9中),这将增加更多选项来限制容器中的操作,这也是毫无价值的。

不,你不是。

或者,换一种说法,如果你误会了,有很多安全专家也有同样的错误。举几个突出的例子:

- 专家在这里采访了关于 Docker 安全性,特别是关于守护进程根问题的问题。包括来自 CERT 的人:

是的,没错,Docker 和许多其他容器技术都需要 root 访问权限才能发挥作用。而且,与任何其他需要 root 访问权限的程序一样,强大的功能带来了造成严重破坏的绝佳机会。

正如卡内基梅隆大学 CERT 研究员 Aaron Cois 最近告诉 DevOps 出版物,“我看到 Docker 的最大威胁之一是它的定位和语言中隐含的安全性。现实情况是这些容器不包含任何东西。” 使用root访问确实是这种情况。

此外,在容器中以 root 权限运行任何东西显然是有问题的“在容器中以 root (UID 0) 身份运行的进程在与内核交互时在底层主机上具有 root 级别的权限。”

那篇文章提供了更多关于与守护进程的根状态相关的问题的细节,并很好地概述了 Docker 总体上有点令人担忧的安全问题。

-这是一个非常好的分析,来自一个团队,讨论了有关 Docker 的许多安全问题,包括一些与 daemon-as-root 架构直接相关的问题,以及如何对抗/缓解它们。此处的演示者总体上对 Docker 安全性提供了一种混合的或有些积极的看法,但他们清楚地表明,在创建设置时必须考虑许多可能的威胁向量。

你明白了,我想。(谷歌揭示了更多阐明这些观点的文章,在过去一年左右的时间里,我个人在这里和那里阅读了一些其他文章。)现在,我并没有用任何想象力来抨击 Docker,似乎你在如何设置和维护东西时小心,你可以大大减少 Docker 不那么可靠的安全架构允许存在的威胁,包括作为 root 的守护进程。(当然,容器使用起来既简单又方便。)但是你肯定,当然,你担心 Docker没有使用一个好的,现代的方法,包括最大合理的权限减少(正如 Docker 所代表的那样)至少今天)。

来自RHEL Docker 支持团队的负责人 Daniel Walsh (所以不是那种有任何理由反对 Docker 的人)关于 Docker 安全性的文章也很有趣。关键思想之一是必须“假设在容器内运行的特权进程与在容器外运行的特权进程相同。 ”。

这是一篇相对较旧的文章,2014 年 7 月。Linux 容器(依赖于 Docker)已经发展,并在 2014 年 1 月引入了非特权容器,确保容器内的特权进程现在以主机系统点的最终用户特权运行-看法。

然而,这个特性在 Docker 中仍然不被支持,并且被推迟了好几次。

在另一个关于 Docker 安全的答案中,我还提到了其他几个面向安全的项目,这些项目在由于安全问题而离开之前依赖 Docker。

因此,正如您所说,Docker“承诺简化我们的部署并提供许多其他设计和运营优势”,这当然是正确的,并且似乎是 Docker 的主要目标,但正如 Daniel Walsh 强调的那样,通过隔离实现安全并不是这些承诺的一部分。

通常在安全性和功能性之间存在折衷。Docker 似乎将自己定位在阶梯的功能方面。由您决定 Docker 功能所增加的价值是否值得。