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

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

容器不包含

我听到并读到很多人都认为Docker容器实际上是沙箱应用程序-意味着他们可以使用Docker作为根在自己的系统上运行随机应用程序。 他们认为Docker容器实际上将保护其主机系统。

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

“你会走进我的客厅吗？” 蜘蛛对苍蝇说 。

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

你关心？

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

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

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

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

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

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

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

可能出什么问题了？

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

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

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

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

那是什么问题呢？ 为什么容器不包含容器？

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

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

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

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

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

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

设备未命名空间：

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

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

翻译自: https://opensource.com/business/14/7/docker-security-selinux