Docker 容器真的安全吗？

本文基于我今年在DockerCon上的演讲。它将讨论 Docker 容器安全性，我们当前的位置以及未来的发展方向。

这是有关 Docker 安全性的系列文章的一部分，请阅读第二部分。

Containsers do not contain

我听到并读到很多人以为 Docker 容器实际上是沙箱应用程序（sandbox-applications）的意思，这意味着他们可以使用 Docker 以 root 身份在系统上运行随机应用程序。他们认为 Docker 容器实际上将保护其主机系统。

• 我听说有人说 Docker 容器与在单独的 VM / KVM 中运行进程一样安全。
• 我知道人们正在下载随机的 Docker 映像，然后在其主机上启动它们。
• 我甚至看到一些 PaaS 服务器（还不是 OpenShift ）允许用户上载自己的映像以在多租户系统上运行。
• 我有一个同事说：“ Docke r是要运行从 Internet 下载的随机代码并以 root 用户身份运行它。”

“你会走进我的客厅吗？” 蜘蛛对苍蝇说。（《蜘蛛与苍蝇》是玛丽·豪伊特（ Mary Howitt，1799–1888）的一首诗，于1828年出版。这首诗的第一行是“'您会走进我的客厅吗？'”。蜘蛛对苍蝇说。” 故事讲述了一个狡猾的蜘蛛通过诱使和操纵将一只苍蝇捕获到其网中。这首诗是一个告诫性的故事，反对那些使用奉承和魅力掩饰其真实意图的人们。）

不要再假设 Docker 和 Linux 内核可以保护您免受恶意软件的侵害。

Do you care?

如果您不是在多租户系统上运行 Docker，并且对容器内运行的服务使用了良好的安全性实践，则可能不必担心。你只需假设在容器内运行的特权进程与在容器外运行的特权进程是相同的即可。

有些人错误地将容器视为一种更好，更快的运行虚拟机的方法。从安全的角度来看，容器（比虚拟机在安全方面）要脆弱得多，我将在本文后面进一步介绍。

如果您像我一样相信，则应将 Docker 容器视为“容器服务”，即被视为运行 Apache 的容器，就像对待系统上运行的Apache 服务一样。这意味着您将执行以下操作：

• 尽快放弃特权
• 尽可能以非 root 用户身份运行服务
• 将容器内的根 root 视为容器外的 root

当前，我们告诉“ 通用标准（Common Criteria）”中的人员以与在容器外部运行的特权进程相同的标准来对待容器中的特权进程。

不要在系统上运行随机的 Docker 映像。在很多方面，我都认为 Docker 容器的革命与 1999 年左右的 Linux 革命相似。当时，当管理员听到新的酷炫 Linux 服务时，他们会：

• 在 rpmfind.net 等网站或随机网站上的互联网上搜索软件包
• 将程序下载到他们的系统上
• 如果通过RPM安装或进行安装
• 特权运行

What could go wrong?

两周后，管理员听说 zlib 漏洞，必须弄清楚他们是否希望自己的软件容易受到攻击，同时希望并祈祷这不是漏洞！

这是Red Hat发行版和其他一些受信任的各方介入的地方，以度过难关。红帽企业Linux为管理员提供：

• 他们可以从其下载软件的受信任存储库
• 安全更新以修复漏洞
• 一个安全响应团队来查找和管理漏洞
• 一组工程师来管理/维护软件包并致力于增强安全性
• 通用标准认证，用于检查操作系统的安全性

仅运行来自受信任方的容器。我相信您应该继续从过去获得过代码的人那里获得代码/软件包。如果代码不是来自内部或受信任的第三方，请不要依赖容器技术来保护您的主机。

So what is the problem? Why don't containers contain?

最大的问题是 Linux 中的所有内容都没有命名空间。当前，Docker 使用五个命名空间来更改系统的进程视图：进程 Process，网络 Network，安装 Mount，主机名 Hostname，共享内存 Shared Memory。

尽管这些为用户提供了一定程度的安全性，但它绝不是像KVM那样全面的。在KVM环境中，虚拟机中的进程不会直接与主机内核对话。他们无权访问/ sys和/ sys / fs，/ proc / *之类的内核文件系统。

设备节点用于与VM内核而非主机进行通信。因此，为了使VM上的特权升级，该过程必须对VM的内核进行子虚拟化，在 HyperVisor 中找到漏洞，突破 VM 上非常紧密的 SELinux 控件（sVirt），最后攻击主机核心。

在容器中运行时，您已经到了与主机内核对话的地步。

主要内核子系统的命名空间不像以下那样：

• SELinux
• Cgroups
• / sys 下的文件系统
• /proc/sys，/proc/sysrq-trigger，/proc/irq，/proc/bus

设备未命名空间：

• /dev/mem
• /dev/sd* 文件系统设备
• Kernel Modules 内核模块

如果您可以通过特权进程来通信或攻击其中之一，则可以攻陷该系统。

关于作者

Daniel J Walsh, 图片来自 opensource.com

Daniel J Walsh - Daniel Walsh在计算机安全领域工作了近30年。Dan于2001年8月加入RedHat。Dan自2013年8月以来一直领导RHEL Docker支持团队，但从事容器技术工作已有几年了。他领导了SELinux项目，专注于应用程序空间和策略开发。Dan帮助开发了sVirt，安全虚拟化。他还创建了SELinux Sandbox，Xguest用户和Secure Kiosk。Dan之前曾在Netect / Bindview工作...

更多关于Daniel J Walsh