保护您的容器之三大挑战

在保护容器和容器化生态系统时存在一些陷阱。让我们详细讨论前三大挑战，以便您应对它们。

一种经济高效且不太复杂的虚拟机（容器）替代方案彻底改变了应用程序交付方法。它们显着减少了管理应用程序基础设施的 IT 劳动力和资源。然而，在保护容器和容器化生态系统的同时，软件团队遇到了许多障碍。特别是对于习惯于更传统的网络安全流程和策略的企业团队。我们通常鼓吹容器提供更好的安全性，因为它们将应用程序与主机系统以及彼此隔离开来。在某些地方，我们让它听起来像是天生安全，几乎无法抵御威胁。但这个想法有多牵强呢？让我们直接进入它。

让我们对市场的情况有一个高层次的了解。据美国商业资讯报道，到 2027 年，全球容器安全市场规模预计将达到 39 亿美元，复合年增长率为 23.5%。

与任何软件非常相似，容器化应用程序可能会成为安全漏洞的牺牲品，包括错误、身份验证和授权不充分以及配置错误。

容器威胁模型

让我们了解下面的容器威胁模型：

容器中可能存在的脆弱因素

• 外部攻击者（来自外部）试图访问我们的部署之一（特斯拉被加密黑客攻击）。
• 对生产环境具有一定访问权限的内部攻击者（不一定是管理员）。
• 恶意内部因素是有权访问部署的开发人员和管理员等特权内部用户。
• 无意的内部因素可能会意外导致问题，例如在容器镜像中不小心存储了一些密钥或证书。
• 通过引入一些新服务或减少等待时间来增强客户体验，公司往往会在其服务器或防火墙中打开一些端口。如果不严防死守，这里很可能成为黑客的通道。

可能有多种途径会损害您的容器安全性（上图对此进行了大致总结）。让我们准确地讨论其中的一些因素。

挑战

一、容器镜像的问题

不仅仅是拥有恶意软件。配置不当的容器镜像可能是引入漏洞的原因。当人们认为他们可以旋转自己的图像或从云端下载并直接开始使用时，问题就开始了。我们应该知道，每天都会在云上引入新的漏洞。每个容器镜像都需要单独扫描以证明它是安全的。

要避免的一些已知案例

• 如果映像启动允许未经授权的网络访问的无关守护程序或服务怎么办？
• 如果它被配置为使用比必要更多的用户权限怎么办？
• 另一个需要注意的危险是镜像中是否存储了任何密钥或凭证。

注意：从以上所有案例中，我们注意到 Docker 始终会将其自己的网络优先于您的本地网络。

建议

• 从受信任的容器注册表中拉取图像。受信任的容器注册表配置不当。通常指的是私有注册中心，但不一定，除非它们是加密的并且具有经过身份验证的连接。这应该包括与现有网络安全控制联合的凭据。
• 容器注册表应进行频繁的维护测试，以使其不存在任何具有挥之不去的漏洞的陈旧图像。
• 在将它们投入生产之前，软件团队需要通过蓝绿部署或容器更改的回滚来构建共享实践。

2.注意您的编排安全

在解决安全问题时，像 Kubernetes 这样流行的编排工具是不可或缺的。它已成为主要的攻击面。

据Salt Security称，大约 34% 的组织完全没有适当的 API 安全策略。除此之外，27% 的受访者表示他们只有一个基本策略，包括对 API 安全状态进行最少的扫描和手动审查，并且没有对其进行控制。

当 Kubernetes 处理多个容器时，它在某种程度上暴露了一个很大的攻击面。当我们没有保护编排器的生态系统时，遵循全行业实践的字段级令牌化是不够的。因为敏感信息被解码和暴露只是时间问题。

建议

• 确保 orchestrator 的管理界面被正确加密，这可以包括双因素身份验证和静态数据加密。
• 将网络流量分离到离散的虚拟网络中。这种隔离应该根据传输的流量的敏感性来完成。（例如，面向公众的 Web 应用程序可以归类为低敏感度工作负载，而像税务报告软件这样的东西可以归类为高敏感度工作负载并将它们分开。这个想法是确保每个主机运行特定安全级别的容器。）
• 最佳实践可以是坚持对集群节点之间的所有网络流量进行端到端加密，还包括集群成员之间经过身份验证的网络连接。
• 我们的目标应该是将节点安全地引入集群，在每个节点的整个生命周期中保持一个持久的身份。（在不影响集群安全的情况下隔离/移除受感染的节点）。

3. 防止“docker逃逸”

流行的容器运行时，如 containerd、CRI-O 和 rkt 可能已经随着时间的推移强化了它们的安全策略，但是，它们仍然有可能包含错误。这是一个需要考虑的重要方面，因为它们可以允许恶作剧代码在“容器逃逸”中运行到主机上。

如果您还记得在 2019 年，在 runC 中发现了一个名为Runscape的漏洞。

这个错误 ( CVE-2019-5736) 有可能使黑客能够脱离沙盒环境并授予对主机服务器的根访问权限。这导致整个基础设施受到损害。起初，他们假设它可能是一个恶意的 Docker 镜像，因为里面肯定有一个恶意进程。经过所有测试，他们意识到这是 runC 中的一个错误。

安全需要左移

在处理基于微服务的环境时，最佳实践是在每一步都引入自动化部署。如果我们仍然按照每周或每月的节奏手动执行部署，那么我们就不是敏捷的。要在应用程序交付中真正向左移动，我们需要创建一个现代的安全插件工具链及其在整个管道中的扩展。

它是这样工作的：如果图像中存在任何漏洞，该过程应该在构建阶段就停止。应该对 RBAC 进行定期审计以监控所有访问级别。此外，所有工具和流程都应符合 CIS 基准。

一个好的方法是采用安全即代码实践，将 Kubernetes 原生 YAML 文件的安全清单编写为自定义资源定义。这些是人类可读的，并在运行时声明应用程序的安全状态。现在，可以将其推送到生产环境中并使用零信任模型进行保护。因此，管道外的代码永远不会有任何更改。

总结

是时候总结一下容器化和容器安全处理了。我的目标是在实践容器化时突出一些容易实现但被高度忽视的区域。如今，跨 CI/CD 管道的自动化安全流程和声明式零信任安全策略已成为当务之急。它们提高了开发人员的工作效率，并且是 DevOps 最佳实践的一部分。