共计 2157 个字符，预计需要花费 6 分钟才能阅读完成。
容器凭借其经济高效的劣势扭转了应用程序的交付形式，随着容器的广泛应用，管理应用程序基础设施的 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/se…
https://www.businesswire.com/…
https://www.oreilly.com/libra…
