红帽发布了一份最新的 “2022 年 Kubernetes 安全状况” 报告，调查了组织在云原生开发方面面临的安全挑战，以及他们如何应对这些挑战以保护其应用程序和 IT 环境。该报告基于对 300 多名 DevOps、工程和安全专业人员的调查，重点介绍了公司如何在采用容器和 Kubernetes 的同时平衡这些环境的安全性。

 

报告指出，与前几年类似，安全仍然是容器采用的最大问题之一。新技术与传统 IT 环境集成时可能会带来无法预料的安全挑战，而鉴于容器的安全需求横跨应用程序生命周期的所有方面，从开发到部署和维护，容器呈现出特别复杂的情况。该报告发现，31% 的受访者对容器策略最常见的担忧是对容器的安全威胁和容器安全投资不足。

 

有 93% 的受访者在过去 12 个月中在其 Kubernetes 环境中至少经历过一次安全事件，该事件有时也导致了受访者收入或客户的流失。过去一年，超过一半的受访者（55%）还因为安全问题不得不推迟他们应用程序的推出。对此，报告将责任归咎于 Kubernetes 主要是专注于生产力而不是安全性。“Kubernetes 和容器虽然功能强大，但却是为开发者的生产力而设计的，不一定是为了安全。例如，默认的 pod-to-pod 网络设置允许开放通信，以快速启动和运行一个集群，但却牺牲了安全加固。”

 

报告称，人为错误仍然是导致数据泄露的原因之一；其引用了世界经济论坛的一份研究报告进行佐证，“人为错误是 95% 的数据泄露事件的主要促成因素”。数据表明，在过去的 12 个月里，近 53% 的受访者在他们的环境中经历了错误配置事件。38% 的人发现了一个重大的漏洞，30% 的人说他们遭遇了运行时安全事件；还有 22% 的人说他们没有通过审计。

 

相较于媒体广泛关注的网络攻击，IT 人员最为担心的也还是错误配置所造成的风险。“Kubernetes 是高度可定制的，具有可以影响应用程序安全状态的各种配置选项。因此，受访者最担心由于容器和 Kubernetes 环境中的错误配置而导致的风险（46%）—— 几乎是对攻击的担忧程度（16%）的三倍”。尽可能的自动化配置管理则有助于缓解这些问题。

 

另一方面，DevSecOps 已逐渐成为一些组织的标准。绝大多数受访者（78%）表示，他们在初级或高级阶段都有 DevSecOps 计划。在 DevSecOps 方面，27% 的受访者认为自己所在的是最具前瞻性的组织，他们采用先进的 DevSecOps 计划，在整个应用程序生命周期中集成和自动化安全性。

 

开发、运维和安全团队之间的协作也被重视起来。报告指出，受当今快速的发布周期影响，安全性已经必须左移并嵌入到 DevOps 工作流中，而不是在应用程序即将部署到生产中时才考虑；大部分受访者都对这一观点表示了认同。除了很多人正在实施 DevSecOps 之外，只有 22% 的受访者表示他们继续将 DevOps 与安全分开操作；且只有 16% 的受访者确定他们将由中央 IT 安全团队负责 Kubernetes 的安全。

 

红帽方面总结称，尽管存在潜在的安全问题，但采用容器和 Kubernetes 的好处仍然大于弊端。关键是寻找一个容器和 Kubernetes 安全平台，将 DevOps 最佳实践和内部控制作为其配置检查的一部分。它还应该评估 Kubernetes 本身的配置的安全状况，以便开发人员可以专注于功能交付。