Docker 的安全基准

Docker 公司与 Center for Internet Security （ CIS ）合作，制作了一份基准文档 [pdf]，包含很多针对部署 Docker 的安全性的建议。Diogo Mónica 在一篇博客“理解Docker 的安全性和最佳实践”中公布了该基准，最近她和Nathan McCauley 一起受雇来领导 Docker 的安全团队。该团队也发布了“容器安全性入门”[pdf] 白皮书。

基准文档涵盖了运行Docker 的宿主（系统）的配置、Docker 本身的配置，以及在Docker 管理下运行的容器的配置。该基准针对Docker 1.6.0，（这是）本文写作时的最新版本，并且基于（使用）红帽企业Linux（RHEL）第7 版或Debian 第8 版作为宿主操作系统（OS）。基准的附录中有包含每项建议的检查清单。

建议分为两个级别，第一级涉及的措施“实用而谨慎，提供明确的安全方面的好处，而又不妨碍运用的技术超出可接受的范围。”第二级的建议更加具有侵入性，被描述为“针对把安全性视为头等大事的环境或情况，作为深入全面的防御措施，或者会消极地抑制技术的运用或性能。”第一级的建议适用于宿主操作系统和 Docker，而第二级的3 项关于强制访问控制（mandatory access control，MAC）和端点保护平台（endpoint protection platform，EPP）的建议，只适用于Docker。

很多建议在其审核一节有脚本片段，可以用来判断配置是否 处于所需的状态，这表明，大部分基准可以组织成脚本，用来检查（及重新配置）宿主是否符合基准。补救措施在适当的情况下也用脚本片段描述，但是这些脚本不太有用，因为在大多数情况下，必须编辑启动配置。鉴于所有主要的Linux 发行版本现在都切换到systemd 作为其默认的启动系统，CIS 可能会选择显 示与此相应的配置步骤，但这也有可能会造成许多仍在旧发行版本上运行Docker 的用户的困惑。

尽管有些建议是相当通用的，比如“不要在生 产环境使用开发工具”，大多数建议还是很具体和可操作的，比如“不要使用aufs”。因此该基准可以用来剖析某一Docker 环境，决定可以采取以提高其安全性的实际步骤。当由于底层宿主操作系统的不同而存在多种选择时，就会给出由Docker 核心团队和其他人撰写的很多外部指导性文档。

一些可能以前被认为是容器的最佳实践，比如，“一个容器只包含一个进程”，以及，“不要在容器内运行SSH”，在基准中作为安全性的建议。把这认为是安全性的问题，将有可能进一步削弱把容器作为小型虚拟机的使用模式。

基准中有一些特别之处希望能在将来的版本中解决。其中之一是在Docker 将来的版本中对用户命名空间的支持，表明这有可能出现在1.6 版本中（即使该基准就是关于1.6 版本的）。这也许说明用户命名空间的整合的确要比预想的更成问题。基准还建议使用 nsenter ，尽管其使用已经在很大程度上被 Docker 1.3 引入的‘exec’命令所取代。

伴随基准推出的白皮书表明，Docker 公司正努力把容器定位为改进安全性的方法，但就象任何新技术一样，公司面临艰难的时刻说服对安全性有顾虑的客户，在生产环境运行是安全的。CIS 基准的发布为那些想在生产环境运行 Docker 的（用户）提供了可测量的手段来评估其安全状况，这很可能有助于缓解任何顾虑。对于拥抱 Docker 来打包应用程序、加速持续交付管道、以及促进微服务架构的开发者，这应当使（部署）到生产环境中的最后步骤在一定程度上更加容易。

查看英文原文： Docker Security Benchmark

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。