玩转Docker要遵守的8条安全准则

无论大家是否知情，相信已经有相当数量的软件（或者虚拟）容器运行在您的企业当中，甚至开始在生产环境中发挥作用。遗憾的是，多数安全团队仍不了解容器技术的安全含义，甚至不清楚自家环境中是否存在容器因素。

总体来讲，Docker与CoreOS Rkt等容器技术能够对应用进行虚拟化——而非完整服务器。容器具备出色的轻量化优势，且无需复制访客操作系统。其灵活、可扩展且易于使用，同时能够在单一物理基础设施内纳入更多应用。由于使用共享式操作系统而非单一系统，因此容器往往能够在瞬间完成引导（虚拟机则普遍需要数秒乃至数分钟）。

考虑到开发者与DevOps团队已经广泛接纳容器技术，我们必须直面由此带来的负面影响——即容器带来了新型安全挑战。

1． 引入存在漏洞的源代码： 由于容器技术多为开源项目，因此开发者创建的镜像需要经常更新，以备必要时使用。这意味着可能带来代码受控性薄弱、存在漏洞或者引发意外状况等问题。

2． 增大攻击面：在指定环境中，容器的数量往往要多于应用、虚拟机、数据库乃至其它需要保护的对象。容器的数量越多，对其进行追踪就越是困难，而检测异常状况自然也更难以实现。

3． 缺乏可观察性： 容器由容器引擎负责运行，例如Docker或Rkt，同时与Linux内核相对接。由此带来的全新抽象层将导致我们很难发现特定容器中的活动或者特定用户在其中执行的操作。

4． Devops速度： 容器的生命周期平均只相当于虚拟机的四分之一。容器能够立即执行，运行几分钟，而后被停止并删除。这意味着恶意人士能够借此发动闪电打击，而后马上消失无踪。

5． 容器间干扰： 容器可彼此协作以用于建立DoS攻击。例如，反复开启嵌套会快速导致整体主机设备陷入卡顿并最终宕机。

6． 容器突破主机： 容器可作为root用户运行，这使其能够利用高权限以突破"围堵"及访问主机操作系统。

7． 横向网络攻击： 单一容器的破坏可能导致其所在整体网络遭遇入侵，特别是在对外网络连接且原始嵌套运行未作适当限制的情况下。

考虑到以上几点，我整理出了这份最佳实践列表，希望能够为大家的容器安全保障工作带来启示。

1． 采用综合性漏洞管理方案。安全漏洞管理工作绝不仅限于扫描镜像，还需要贯穿整个容器开发周期进行访问控制并配合其它策略，否则很可能导致应用崩溃或者运行时入侵。严格的漏洞管理方案应该利用主动性多项检查完成"从摇篮到坟墓"的全面监控，同时利用自动触发机制控制开发、测试、分段与生产环境。

2． 确保仅在环境中运行获准镜像。在开发环境中控制所引入之容器镜像能够有效缩小攻击面并预防开发者造成致命安全错误。这意味着仅使用获准注册镜像及对应版本。举例来说，大家可以将单一Linux发行版指定为基础镜像，并借此最大程度控制潜在攻击面。

3． 实施贯穿整个生命周期的主动完整性检查。作为容器生命周期安全管理中的重要组成部分，我们需要确保注册表中的容器镜像具备理想的完整性，同时在镜像进行变更或者凙时执行进一步控制。镜像签名或指纹可提供一套保管链，帮助大家轻松验证容器完整性。

4． 在运行时强制执行最低权限原则。作为一项基础性安全最佳实践，其同样适用于容器技术。在攻击者利用漏洞时，其通常能够获取已入侵应用或进程的访问及其它操作权限。确保容器始终仅具备最低权限能够显著降低入侵后引发的暴露风险。

5． 为容器允许访问或运行的文件及可执行文件设置白名单。白名单能够帮助大家控制并管理文件与可执行文件，同时确保其仅在需要特定功能时得以使用。如此一来，我们的环境将更加稳定可靠。建立预核准或者白名单机制能够显著缩小攻击面，同时作为基准参考防止容器干扰及容器入侵等问题。

6． 在运行中的容器上进行网络隔离。 维持网络隔离性以按照应用或者工作负载进行容器集群或者容器区划分。这一举措除了属于高效最佳实践外，还属于受PCI DSS管理的必备容器应用原则，同时亦可预防横向攻击活动。

7． 主动监控容器活动及用户访问。 与其它IT环境一样，大家同样需要对容器生态系统进行活动与用户访问监控，从而快速发现异常或者恶意活动。

8． 记录全部管理用户访问活动以进行审计。虽然强大的用户访问控制机制能够限制大多数人－容器交互操作，但管理员无疑不在受控范围之内。因此，我们必须设置日志管理以记录各类管理性操作，从而在必要时提供取证信息以及明确的审计线索。

尽管相较于其它早期解决方案，容器技术的安全性水平天然更高。然而