容器安全的三大挑战_容器技术带来了哪些新的安全风险

容器凭借其经济高效的优势改变了应用程序的交付方式，随着容器的普遍使用，管理应用程序基础设施的 IT 劳动力和资源也显著减少。然而，在保护容器和容器化生态系统时，软件团队遇到了许多障碍。尤其是习惯于更传统的网络安全流程和策略的企业团队。从理论上来说，容器看起来似乎能够提供更好的安全性，因为容器将应用程序与主机系统彼此隔离开来。但实际真的如此吗？
 

让我们来看一组市场数据。据美国商业资讯报道，到 2027 年，全球容器安全市场规模预计将达到 39 亿美元，复合年增长率为 23.5%。显而易见，市场对于容器安全的需求将越来越大。与任何软件一样，容器化应用程序也可能受到安全漏洞影响，包括错误、身份验证和授权不充分以及配置错误，因此容器安全问题不容忽视。
 

容器中的安全威胁

容器中可能存在的安全威胁有：

• 外部攻击者试图访问企业部署。

• 对生产环境具有一定访问权限的内部攻击者（不一定是管理员）。

• 有权访问部署的开发人员和管理员等特权内部用户的有意破坏。

• 无意的内部因素可能会意外导致问题，例如在容器镜像中不小心存储了一些密钥或证书。

• 通过引入一些新服务或减少等待时间来增强客户体验，公司往往会在其服务器或防火墙中打开一些端口。如果不严防死守，这些端口很可能成为黑客的通道。

图片来源：Container Security by Liz Rice
 

上述多种途径会损害企业的容器安全性。接下来我们将一起来讨论容器安全面临的挑战以及应对建议。
 

容器安全面临的挑战

1. 容器镜像问题

引入漏洞将会导致配置不当的容器镜像。事实上每天云端都会引入不同的新漏洞。如果用户直接从云上获取镜像并直接开始使用，就会存在一定安全风险。所以每个容器镜像在使用之前都需要进行单独扫描从而保证其安全性。
 

常见的一些问题案例：

• 镜像启动允许未经授权的网络访问的无关程序或服务

• 容器镜像被配置超出用户使用的普通权限（配置的权限大于用户使用）

• 镜像中存储了密钥或凭证
   

建议：

• 从受信任的容器镜像仓库中拉取图像，因为这类的镜像仓库通常拥有良好的配置，通常指的是私有镜像仓库，经过加密并且需要经过身份验证。

• 容器镜像仓库应进行定期频繁的维护测试，以此来减少和消除包含漏洞的镜像。

• 在将镜像投入生产之前，软件团队需要通过蓝绿部署（Blue-Green deployments）或容器更改的回滚来构建共享实践。
   

2. 编排安全问题

在解决容器安全问题时，像 Kubernetes （K8s）这样的编排工具是不可或缺的。目前 K8s 已成为主要的攻击面。据 Salt Security 称，大约 34% 的组织完全没有适当的 API 安全策略。除此之外，27% 的受访者表示他们只有一个基本策略，包括对 API 安全状态进行最少的扫描和手动审查，并且没有对其进行控制。
 

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

建议：

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

3. 防止“容器逃逸”问题

使用较多的容器运行时例如 containerd、CRI-O 和 rkt，可能已经随着时间的推移强化了它们的安全策略，但是，它们仍然无法避免漏洞问题。这是一个严重的安全问题，因为这些容器运行时允许恶意代码在“container escape”中运行到主机上。
 

在 2019 年，runC 中发现了一个名为 Runscape 的漏洞。这个漏洞 ( CVE-2019-5736) 能够让黑客能够脱离沙盒环境并授予对主机服务器的根访问权限，从而导致整个基础设施受到损害。起初，人们只是假设这可能是一个恶意的 Docker 镜像，但经过一系列测试后才意识到这是 runC 中的一个危险漏洞。
 

安全左移

在处理基于微服务的环境时，建议在每一步都引入自动化部署。如果仍然按照每周或每月这样的频率来手动执行部署，整个过程就无法达到敏捷状态。要在应用程序交付中真正向左移动，需要创建一个现代的安全插件工具链及其在整个流水线中的扩展。
 

安全左移体现在：如果镜像中存在任何漏洞，该过程应该在构建阶段就停止。应该对 RBAC 进行定期审计以监控所有访问级别。此外，所有工具和流程都应符合 CIS 基准。
 

采用安全即代码实践（SaC）是一个不错的方式，将 Kubernetes-native YAML 文件的安全清单编写为自定义资源定义。这些信息是可读的，并在运行时声明应用程序的安全状态。随即可以将其推送到生产环境中并使用零信任模型进行保护。因此，流水线外的代码永远不会有任何更改。
 

参考链接：
https://dzone.com/articles/securing-your-containers-top-3-challenges
https://www.businesswire.com/news/home/20220516005772/en/Insights-on-the-Container-Security-Global-Market-to-2027—Rising-Threats-and-Cybercrimes-to-Drive-Requirement-for-Container-Security-Platforms—ResearchAndMarkets.com
https://www.oreilly.com/library/view/container-security/9781492056690/ch01.html#ch_container_security