Docker 安全性探讨与实践:实践篇

  • 张天雷

2014 年 9 月 17 日

话题:语言 & 开发架构

Daniel Walsh 是计算机安全领域的专家,有 30 余年的从业经验,非常熟悉容器技术。他在开源网站上发表了两篇文章,一篇讨论 Docker 的安全性,另一篇则着重介绍了 RHEL 如何对 Docker 的安全性进行了大量的增强。本文即是 Dan 第二篇文章的梳理与讨论,主要讨论了 Docker 存在的安全风险以及如何保证它的安全。

在接纳了“容器并不是全封闭”这种思想以后,开源社区尤其是红帽公司,连同 Docker 一起改进 Docker 的安全性,改进项主要包括保护宿主不受容器内部运行进程的入侵、防止容器之间相互破坏。Dan 的团队主要采取了层叠式安全机制,即用多层不同安全技术融合在一起包括资源和数据。这种方法的好处就是,开发者可以尽可能地增加安全防护层,如果一个恶意进程突破了某一层防护,紧接着还有下一层基于不同安全机制的防护。红帽企业版 Linux(RHEL)7 专门为这种层叠式安全机制提供了可选的安全技术,具体如下:

1. 文件系统级防护

  • 文件系统只读:有些 Linux 系统的内核文件系统必须要 mount 到容器环境里,否则容器里的进程就会罢工。这给恶意进程非常大的便利,但是大部分运行在容器里的 App 其实并不需要向文件系统写入数据。基于这种情况,开发者可以在 mount 时使用只读模式。比如下面几个:
    • . /sys
    • . /proc/sys
    • . /proc/sysrq-trigger
    • . /proc/irq
    • . /proc/bus

    用只读模式的好处是,那些在容器里权限比较高的进程也无法向宿主文件系统写入。当然这里需要注意一点,必须要把这些进程 remount 可读写文件系统的能力给禁止。更进一步开发者甚至可以禁止容器 mount 任何文件系统,这需要通过使用 capability 完成,下面会详细解释。

  • 写入时复制:Copy-on-write 的具体解释请读者参考前面的维基百科链接。Docker 采用的就是这样的文件系统。所有运行的容器可以先共享一个基本文件系统镜像,一旦需要向文件系统写数据,就引导它写到与该容器相关的另一个特定文件系统中。这样的机制避免了一个容器看到另一个容器的数据,而且容器也无法通过修改文件系统的内容来影响其他容器。

2. Capability 机制

Linux 对 Capability 机制阐述的还是比较清楚的,即为了进行权限检查,传统的 UNIX 对进程实现了两种不同的归类,高权限进程(用户 ID 为 0,超级用户或者 root),以及低权限进程(UID 不为 0 的)。高权限进程完全避免了各种权限检查,而低权限进程则要接受所有权限检查,会被检查如 UID、GID 和组清单是否有效。从 2.2 内核开始,Linux 把原来和超级用户相关的高级权限划分成为不同的单元,称为 Capability,这样就可以独立对特定的 Capability 进行使能或禁止。

通常来讲,不合理的禁止 Capability,会导致应用崩溃,因此对于 Docker 这样的容器,既要安全,又要保证其可用性。开发者需要从功能性、可用性以及安全性多方面综合权衡 Capability 的设置。Dan 在文中给出了 Docker 现有的 Capability 清单:chown、 dac_override、 fowner、 kill、 setgid、 setuid、 setpcap、 net_bind_service、 net_raw、 sys_chroot、 mknod、 setfcap 以及 audit_write。目前 Docker 安装时默认开启的 Capability 列表一直是开发社区争议的焦点,作为普通开发者,可以通过命令行来改变其默认设置。熟悉 Linux 内核的读者会发现,Docker 提供的 Capability 是相对较少的。Dan 在文中给出了 Docker 移除的 Capability 列表,并以 CAP_NET_ADMIN 为例,强调容器的设计应该是启动时配置好网络,而非从其内部修改,解释了容器安全性和 Capability 的 权衡,感兴趣的读者可以深入阅读。

3. NameSpace 机制

Docker 提供的一些命名空间也从某种程度上提供了安全保护,比如 PID 命名空间,它会将全部未运行在开发者当前容器里的进程隐藏。如果恶意程序看都看不见这些进程,攻击起来应该也会麻烦一些。另外,如果开发者终止 pid 是 1 的进程命名空间,容器里面所有的进程就会被全部自动终止,这意味着管理员可以非常容易地关掉容器。此外还有网络命名空间,方便管理员通过路由规则和 iptable 来构建容器的网络环境,这样容器内部的进程就只能使用管理员许可的特定网络。如只能访问公网的、只能访问本地的和两个容器之间用于过滤内容的容器。

4. Cgroups 机制

主要是针对拒绝服务攻击。恶意进程会通过占有系统全部资源来进行系统攻击。Cgroups 机制可以避免这种情况的发生,如 CPU 的 cgroups 可以在一个 Docker 容器试图破坏 CPU 的时候登录并制止恶意进程。Dan 表示,需要设计更多的 cgroups,用于控制那些打开过多文件或者过多子进程等资源的进程。类似的在文中 Dan 还介绍了设备 cgroups。

5. SELinux

SELinux 是一个标签系统,进程有标签,每个文件、目录、系统对象都有标签。SELinux 通过撰写标签进程和标签对象之间访问规则来进行安全保护。它实现的是一种叫做 MAC(Mandatory Access Control)的系统,即对象的所有者不能控制别人访问对象。具体可以参见 Dan 的这篇文章。至于如何用 SELinux 来进行容器的安全防护,Infoq 会有另一篇文章来详细介绍 Dan 的思想。

总而言之,为了保证 Docker 容器的安全性,Dan 的团队尝试了非常多的安全机制,但是正如之前一篇文章中讲的,安全不在于机制的健全,而在于管理员自身的防范。在文章的结尾,Dan 给出了管理员应该注意的一些事项,如只运行来自可信来源的应用,在安全防护比较好的宿主机上运行等等。


感谢郭蕾对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

语言 & 开发架构