本文作者 Gadi Naor, Alcide公司联合创始人兼CTO。
近期，谷歌安全团队的Felix Wilhelm在 Red Hat Linux 及其衍生版（如 Fedora 操作系统）的 DHCP 客户端中发现了一个严重的远程命令行注入漏洞。该漏洞编号为 CVE-2018-1111，可能会使得攻击者在目标系统上以 root 权限执行任意命令。
该攻击利用Dynamic Host Configuration Protocal（DHCP）消息处理中的问题——这是机器自动设置其网络连接的方式。在DHCP客户端（dhclient）软件包包含的脚本中发现了命令注入漏洞，允许攻击者伪装成合法的DHCP服务器，发送包含恶意命令的特制数据包，而DHCP客户端可能会毫无疑问地执行这些命令。此漏洞影响红帽EnterpriseLinux 6和7以及各种Linux衍生发行版，如Fedora和CentOS。
以此漏洞为例，我们可以看到云提供商与其客户之间传统的“责任共享”安全模式对于容器化工作负载来说效率会降低。由于网络插件已经成为在容器之间提供网络连接的标准方式，因此云提供商没有加强自己保护容器安全的责任，而当打补丁不足以保护容器化应用程序时，安全和运维团队就会陷入困境。
在这个新的范式中，安全和运维团队必须采用新的工具和策略来确保对容器化环境的完全可见性。
什么是责任共享模式？
云提供商为其客户提供“责任共享”模式：云提供商负责基础设施和管理云的安全性。客户负责保护在云中运行的所有内容。你拥有对所有数据、应用程序和操作系统的完全所有权和控制权，那么你有责任保护它们。
AWS Fargate和Azure ACI等服务将上述模型扩展到容器世界。使用容器即服务时，作为Kubernetes工作节点的Container主机是你的“容器管理程序”，Container Network Interface是你的网络转发提供程序。
我们会发现责任界限变得模糊，因为你的环境与提供商的环境之间的界限开始分崩离析。在传统的责任共享模型下，云提供商负责保护容器和其他环境之间的网络。但是，正如我们在上面的例子中看到的那样，情况不再总是如此——这让安全和运维团队别无选择，只能承担更大的责任。
Container Network Interface和CVE-2018-1111
Container Network Interface（CNI）是一个CNCF项目，由一个规范和多个库组成，用于编写插件以配置Linux容器中的网络接口。该框架仅关注容器的网络连接，并且大量用于容器化部署。Kubernetes、Docker以及使用Docker网络协调容器网络的任何东西都支持多个CNI插件。
在这个丰富的控制工作负载与主机网络之间的连接的网络插件生态系统中，运维和安全团队可能很难确保正在运行的工作负载不会利用网络从容器横向移动（换句话说就是东西移动）到主机本身甚至是邻近容器主机。
有DHCP客户端漏洞的CVE-2018-1111是潜在容器逃逸的另一个例子。它可能会让容器中的错误代码直接在容器主机上执行命令。防止此类攻击取决于底层容器网络接口插件的开箱即用分段和隔离功能。在容器主机上运行的任何本地网络服务（例如DHCP、DNS和NTP）都可能是基于网络的攻击的常见嫌疑对象，这些攻击可以促进东西向容器的迁移和权限提升。
显然，Ops和DevOps必须将可用的补丁应用于其数据中心和云中的所有易受攻击的主机，以防止攻击者接管计算基础设施。
但是，负责保护现代数据中心的团队应该牢记，定期将安全补丁应用于基础设施的做法很快就会失效。还应该与虚拟工作负载（如虚拟机、容器甚至连接到网络的无服务器功能）的运行时保护相辅相成。此工作负载级别的运行时保护必须实施策略，以最大限度地减少网络堆栈中的意外连接路径，并隔离受损的虚拟工作负载。
完美情况下，云提供商就提供了大多数的这些功能。但是，运维和安全团队无法再确定确切的责任共享从哪里开始，在哪里结束。实现更高安全性的最佳方法是投资工具和程序，以确保更好地可见容器化环境，并提供作为云提供商产品之外附加层的工作负载级的保护。
来源：https://thenewstack.io/containers-break-the-shared-responsibility-model-between-cloud-providers-and-ops/?utm_content=73903350&utm_medium=social&utm_source=twitter
编译：Karen Lee