Docker 与高安全性的微服务：总结 Aaron Grattafiori 于 DockerCon 2016 的发言

Aaron Grattafiori 在美国西雅图举办的 DockerCon 2016 上发表了“金色门票：Docker 与高安全性的微服务”的演讲。其中主要对运行基于容器的安全微服务方案建议：启用用户命名空间、配置应用特定的AppArmor、SELinux 及seccomp 白名单、加固宿主系统（包括运行一个满足要求的最小操作系统）、限制宿主机的访问以及考虑加入网络安全策略。

身为NCC Group 的技术负责人以及《理解及加固Linux 容器（PDF）》的作者，Grattafiori 以全面防御原则的介绍开启了他的演讲，这个原则是由分层的防御措施，并通过减少攻击面，加固剩余的攻击面组成。虽然微服务会增加系统架构的总体复杂度（特别是针对伸缩性方面），但相对一个典型的整体应用，微服务对避免单点安全故障是有一定优势的。

最小权限原则对于系统安全极为重要，比如避免使用root 权限运行应用。一个整体的应用往往使用单一的流程来提供大部分的功能，这使得它很难应用这个原则。最小意外原则——“合理的默认值，基于信任的隔离”——以及最小访问原则也对全面防御起着至关重要的作用。Grattafiori 指出这些原则的共同点是“最小”，这能防止过度性和复杂性，并能让系统构筑师：

1. 建立信任边界
2. 识别、最小化及加固攻击面
3. 降低作用域和访问权限
4. 分层的保护与防御

整体应用安全（AppSec）的好处包括其构建和维护的易于理解及“已知的已知”。这种架构往往相对简单，并且在开发、业务、合规等过程中通常有着根深蒂固的现有习惯（及相关责任分工）。整体应用安全的劣势包括向单点的妥协，往往也意味着对整个应用及网络的妥协、全局的认证需求以及安全机制往往很难协调。

微服务应用安全的好处包括：广为接受的 Unix单一职责原则、普遍减少的公开暴露的攻击面、服务可以被单独打补丁、应用（和相关的运行时容器）更方便地应用最小权限和适应服务特性的安全机制，并且这通常可以更方便地建立可信计算基(TCB) 。相应地，劣势包含：微服务安全是一种“已知的未知”，成功的维护会需要习惯上的改变（如 DevOps 和 DevOpsSec ）、需要对整个系统的功能有一个很好的理解、遗留项目很难适用、复杂性（伸缩性方面）所带来的不安全。

Grattafiori 接下来深入分析了微服务系统各个区域的安全影响，首先是在网络安全方面。虽然大部分软件系统在 OSI 模型7 层（应用层）提供身份认证，这点常被争论为只能提供有限的优势，最好是通过在 4/5 层的 TLS 来实现，如果需要额外的网络安全那么可以实现 3 层的 IPSEC 。

许多组织使用 Linux 容器如 Docker 、 rkt 或 LXC 来包装微服务，这两者之间在安全方面有明显的相似之处：

减少应用和容器的威胁模型攻击树很有必要。这包括通过利用防御性代码和容器安全（如能力（capabilities）、用户命名空间、只读根文件目录（rootfs）、不可变文件、mount 标记（mount flags）和强制访问控制（MAC））来限制由应用弱点所造成的危害。

容器逃逸所造成的伤害可以被用户命名空间限制，它可以让容器中的root 用户对应到容器外的非root（uid-0）用户。虽然Docker 守护进程支持 Docker 1.10 用户命名空间，但是默认是没有开启的。 seccomp 、kernel 加固和 MAC 可以限制 kernel 和 syscall 的调用。受限的 kernel 或主机操作所造成的破坏能进一步被网络加固、信任隔离、最低权限、最小访问、日志和报警所限制。

Grattafiori 表示容器安全始于宿主机的操作系统，并极力推荐使用最小的 Linux 发行版如 CoreOS 、 alpine Linux 、 Project Atomic 或 RancherOS 。对操作员来说理解发行版如何升级、二进制包编译、默认安全配置（如 MAC）和默认 kernel 参数及 sysctl 配置也是非常重要的。

容器镜像也应该保持最小化，典型的如“FROM debian:jessie”或“FROM debian:wheezy”来创建镜像。然而这可能还不够小，就算在用 apt-get 安装应用所需软件之前，已有许多应用用不到的类库、可执行文件和语言文件，这意味着更多的补丁、更多的磁盘空间、更多的攻击面以及更多的攻击方法。

演讲中演示了使用 Docker 和 runC 来构建最小容器的例子，以及几个使用 scratch 容器来运行静态编译的二进制程序（如 Golang 构建的应用）。

Grattafiori 强烈建议使用强制访问控制（MAC），从操作系统角度应用最小访问原则。MAC 引用一种操作系统限制主体（特别是进程或线程）访问或操作对象（如文件、TCP/UDP 端口、共享内存段）的访问控制。MAC 作为一种Linux 安全组件（LSM）是由 AppArmor 和 SELinux （还推荐使用 grsecurity ，它内部包含了一套 MAC 解决方案，是一组强调安全增强的 Linux kernel 补丁）实现的。在 Mac OSX 上 MAC 通过 TrustedBSD 实现，微软平台有强制完整性控制（MIC）。

默认的Docker AppArmor 策略已经非常好了，但是鉴于这个策略是通用的，它一定包含了大量的文件、权限授权和复杂性。微服务更适合使用自定义安全描述文件的实践。基于Docker 的应用的自定义AppArmor 的描述文件可以通过 aa-genprof 或 Jessie Frazelle 的 Bane 项目来生成。然而这需要分析目标应用（因为需要理解和使用这个应用）、常见错误如提供过多权限、通配符的使用和基于路径的访问控制列表（ACLs）。

Grattafiori 提醒应该避免使用 AppArmor 的拒绝列表（黑名单），因为它们只能提供有限的值。其他的易混淆的地方包括描述文件必须先被 AppArmor 加载，在描述文件中太过大量地运用抽象，这导致很难在生产环境中充分验证所有的功能是有效的（虽然单元测试和回归测试会有帮助）。

虽然 MAC 很有价值，但是它还是无法避免 kernel 攻击，不巧 kernel 攻击的攻击面是巨大的。“安全计算模式（seccomp）”是一个计算机安全设备，它在Linux kernel 提供应用的沙箱机制（虽然seccomp 本质上不是沙箱）。seccomp 允许进程单向转变进入“安全”态，在其中只能对已经打开的文件描述符使用exit、sigreturn、read、write 这些系统调用。如果它尝试其他的系统调用，kernel 会使用 SIGKILL 终止进程。 seccomp-bpf 是 seccomp 的一个扩展，它使用伯克利封包过滤器允许使用一个配置的策略来过滤系统调用。

Docker 引擎 1.10 后 seccomp 默认过滤器默认启用，但是由于通用需求，内部启用了 304 个系统调用（占所有系统调用大约 75%）。最小权限原则建议微服务应用只应该拥有最小的系统调用集，相应地可以创建自定义描述文件。创建 seccomp 描述文件的方法包括 strace/ltrace 、kernel 帮助（ sysdig 或 systemtap ）、 auditd/auditctl 或 seccomp 自己通过 SECCOMP_RET_TRACE 和 PTRACE_O_TRACESECCOMP。在 Docker 中可以通过使用“–security-opt seccomp=”标记来指定自定义的 seccomp 描述文件。Grattafiori 强调 seccomp 配置文件是对架构依赖的，所以会限制移植性。

Grattafiori 开始总结演讲时，陈述了运行安全的基于 Docker 的微服务的高层次建议：

• 启用用户命名空间
• 尽可能地使用应用特定的 AppArmor 或 SELinux
• 尽可能地使用应用特定的 seccomp 白名单
• 加固宿主机系统
• 限制宿主机访问权限
• 考虑使用网络安全策略
• 使用不可变的容器

管理构建和运行时秘钥（secrets）的问题可以通过临时绑定 mount 来进行临时秘钥注入，再加载秘钥到内存，然后 unmount；或者理想地使用开源秘钥管理工具如 HashiCorp Vault 或 Square Keywhiz 。秘钥不应该通过环境变量或普通文件注入，因为这很容易导致秘钥泄露到容器层、日志或错误报告中。

最后的安全建议包括创建一个安全规格书、生成应用特定和全局的威胁模型、确保任何应用 / 服务的安全性、确保协调框架和相关服务发现的安全性。

如果应用自身是脆弱的，那么容器和微服务也无能为力

微服务的日志和可计量也很重要，日志应该被统一收集保存，并定期复审。如果把安全融入到软件的开发周期，同时使用 OWASP 的 ZAP 、 bdd-security 、 Brakeman 或 gauntlt 等工具将核实的过程作为标准构建链的一环，这样就更容易达成安全性目标了。

Grattafiori 在 DockerCon 的视频“金色门票：Docker 与高安全性的微服务”可以在YouTube 的会议频道找到，幻灯片可以在 Docker 的 SlideShare 账号找到。Grattafiori 也是 NCC Group 白皮书《理解及加固Linux 容器（PDF）》的作者，这本书对每个正要详细理解容器安全的人是必不可少的。

查看英文原文： Docker and High Security Microservices: A Summary of Aaron Grattafiori’s DockerCon 2016 Talk

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。