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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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