1、Kubernetes 安全状况报告2022 年1执行摘要执行摘要最新版 Kubernetes 安全状况报告分析了容器、Kubernetes 和云原生安全方面的新趋势。报告重点介绍了云原生开发中的安全挑战，以及企业如何解决这些挑战并保护自己的应用。该报告根据来自 300 多名开发运维（DevOps）、工程和安全专家的调查结果，揭示了有关采用容器和 Kubernetes 的各公司为保护其云原生环境而实施“开发、安全和运维”（DevSecOps）计划的新发现。安全性是在容器采用方面最担忧的问题之一，安全问题仍在导致应用部署到生产时出现延迟。我们也调查了公司在 Kubernetes 环境中遇到的最常见

2、安全事件类型，以及他们是否报告了这些事件所导致的客户或营收损失。DevSecOps 正在快速成为在 DevOps 工作流中尽早进行安全测试和解决安全问题的一项标准，超过 3/4 的受访者制定了旨在改善 DevOps 和安全团队之间协作的计划。调查结果突出了开发、运维和安全团队就实现安全性在开发生命周期早期合作的重要性，从而实现 Kubernetes 的最大优势快速创新。我们鼓励您根据本报告中的发现进行自我基准测试，以确定如何进行跨容器和 Kubernetes 应用安全控制。安全防护延误可能导致创新的延误或面临财务损失。您可以利用容器和 Kubernetes 中的许多安全性有利因素声明性配置、不

3、可变基础框架以及容器化应用中的固有隔离。然而，公司需要知识、工具和流程来使这些功能发挥作用，以保证其能在由 DevOps 驱动、云原生的世界中快速运行这一巨大优势中受益。执行摘要关键解读安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全执行摘要关键解读53%的受访者在过去 12 个月内检测到 Kubernetes 配置错误51%的受访者要求开发人员使用经验证的镜像43%的受访者将“DevOps”视为负责保护 Kubernetes 安全的角色57%的受访者最担心运行时的工作负载防护78%的受访者拥有新人入门或高级阶段的 DevSecOp

4、s 计划55%的受访者由于安全问题延后或推迟了应用部署安全性是容器采用方面的最大担忧之一，安全问题仍在导致应用部署到生产时出现延迟。执行摘要关键解读安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全3安全问题安全问题阻碍创新大多数受访者都曾由于安全问题未解决而导致应用交付推迟。企业正在通过采用 Kubernetes 和微服务应用架构等云原生技术，转变他们构建、运行和扩展应用的方式。一些企业将所有新应用构建为微服务，另一些企业在兼顾重构现有应用的同时，对单体式应用进行管理。他们还必须转变在云原生堆栈中实施安全防护的方式。发布周期更短、错

5、误修复更快，以及灵活性更强以在不同混合环境之间运行和管理应用，是容器化最常提及的三大优势。然而，当安全防护成为事后补救措施时，您可能会忽视容器化所带来的最大收益敏捷性。多数受访者（55%）在过去 12 个月中，不得不因为安全问题而推迟应用推出。新技术常常会带来不可预见的安全挑战。一些企业在安全需求方面不堪重负，这些需求覆盖从开发到部署和维护整个应用生命周期的所有层面。他们需要一种简便的方法，不仅能够保护容器化应用，并且不会减慢开发速度或增加运维复杂性。您是否曾因为容器或 Kubernetes 安全问题而延后或推迟将应用部署生产？55%是45%否内容摘要安全问题阻碍创新容器策略责任依旧分散Dev

6、SecOps 得到大规模采用配置不当是首要问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全4安全问题在过去 12 个月内，93%的受访者在 Kubernetes 环境中至少遇到过一次安全事件，这些安全事件有时也造成了营收或客户损失。在过去 12 个月内，93%的受访者在 Kubernetes 和容器环境中遇到过安全事件。这背后综合了诸多因素，如缺乏关于容器和 Kubernetes 的知识、采用不适当或不匹配的安全防护工具，以及中央安全团队跟不上快速移动的应用开发团队的步伐等。结果是，31%的受访者表示，过去 12 个月里曾经因为安全事件

7、而造成营收或客户损失。人为错误依旧是数据泄露的首要原因。近期的一项研究表明，95%的数据泄露中人为错误是首要影响因素。Kubernetes 和容器尽管功能强大，但设计面向的是开发人员生产力，未必重视安全性。例如，默认的容器集间网络设置允许开放式通信，以损失安全强化为代价，让集群快速准备就绪并上线运行。近 53%的受访者过去 12 个月在其环境中遇到过配置错误事件，这个结果并不出人意料。38%的受访者发现了重大漏洞，而 30%的受访者则表示他们在运行时遇到了安全事件。最后，22%的受访者表示没有通过审核。1.世界经济论坛，“2022 年全球风险报告”，2022 年 1 月。在过去 12 个月中，

8、您是否遇到过与容器/Kubernetes 安全性或合规问题/事件相关的营收/客户损失？53%检测到配置错误38%需要修复重大漏洞30%发生运行时安全事件22%未通过审核7%无在过去 12 个月中，您遇到过哪些与容器和/或 Kubernetes 相关的安全事件或问题？（可多选）69%否31%是内容摘要安全问题阻碍创新容器策略责任依旧分散DevSecOps 得到大规模采用配置不当是首要问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全5安全问题安全性是容器策略中的首要问题之一鉴于我们更早的调查结果突显了这些环境中安全事件的普遍性（93%），安

9、全性仍然是容器策略的首要问题这一点也就不足为奇了。总而言之，容器安全威胁相关问题（14%）和容器安全投入欠缺（17%）表明安全性（31%）是容器策略的首要问题。另有 22%的受访者表示进展缓慢是他们最大的问题，而还有 20%受访者则认为技能缺口是他们最大的问题。企业积极采用容器和 Kubernetes，投入云原生生态系统，以促进创新和发展。如果不能同时对安全策略和工具进行必要投资，其关键应用将面临安全风险，甚至可能导致应用推出延误。您公司容器策略最大的担忧是什么？14%没有严肃对待对容器的威胁6%未考虑合规性需求12%未考虑文化或流程变更内容摘要安全问题阻碍创新容器策略责任依旧分散DevSec

10、Ops 得到大规模采用配置不当是首要问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全22%进展过于缓慢20%未解决团队的技能缺口17%容器安全投资不足9%其他6安全问题Kubernetes 的安全职责仍然不够集中，由 DevOps 主导在各种角色中，受访者大多认为由 DevOps 负责保护容器和 Kubernetes。总而言之，高达 78%的受访者认为 DevOps、运维和 DevSecOps 等各种运维人员是 Kubernetes 安全的主要负责人。只有 16%的受访者明确指定由中央 IT 安全团队负责保护 Kubernetes 安全

11、。对此，研究推动采用容器和 Kubernetes 的因素可以获得一些解释。为了推动二者的使用，通常会将 DevOps 作为影子 IT，绕开中央 IT 团队监管，因此受访者指定由 DevOps 负责保护这些技术的安全，也就不足为奇了。为了弥合差距，容器和 Kubernetes 安全工具必须促进不同团队之间的密切协作从 DevSecOps 到运维，再到安全团队而不是使可能困扰公司的团队隔离永久存在。您公司中哪个角色主要负责容器和 Kubernetes 的安全？DevOpsDevSecOps安全运维开发人员43%19%16%16%6%内容摘要安全问题阻碍创新容器策略责任依旧分散DevSecOps 得

12、到大规模采用配置不当是首要问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全7安全问题DevSecOps 得到大规模采用DevSecOps 得到了大多数人的接纳，此术语包含允许将安全构建到应用开发生命周期中的流程和工具，而不是把安全作为一个单独的流程。我们的调查发现了喜闻乐见的消息绝大多数受访者表示他们正在开展某种形式的 DevSecOps 计划。只有 22%的受访者依旧将 DevOps 与安全性分开运作。27%的受访者认为自己在 DevSecOps 方面最有远见，制定了进阶 DevSecOps 计划，在整个生命周期中整合并自动执行安全防

13、护。您公司中是否拥有 DevSecOps 计划？27%是50%是22%否27%是我们正处于后期阶段，在整个生命周期中整合和自动执行安全防护50%是我们正处于早期阶段，DevOps 和安全部门根据联合政策和工作流展开协作22%否DevOps 与安全团队仍然互相独立，协作较少内容摘要安全问题阻碍创新容器策略责任依旧分散DevSecOps 得到大规模采用配置不当是首要问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全8安全问题受访者对配置不当的担忧高于所有其他安全问题Kubernetes 是可以高度自定义的容器编排器，具有各种可以影响应用安全态

14、势的配置选项。因此，受访者最担心“由于容器和 Kubernetes 环境配置不当而导致的风险”（46%），几乎是“受到攻击”（16%）的三倍。第二大担忧因素则是“漏洞”(28%)。配置管理给安全从业者带来了独特且艰巨的挑战。负责配置工作负载的人可能不了解 Kubeneretes 中各种设置的安全含义。虽然有大量工具可用于容器镜像的漏洞扫描，但配置管理需要考虑更多因素，还有可能因企业和团队不同而各不相同，具体取决于风险容忍水平和工作负载敏感程度。人们可能知道应该避免部署 Kubernetes 控制面板，但配置容器集的安全内容或实施 Kubernetes 基于角色的访问权限控制（RBAC）仅仅是说

15、明团队需要更多挑战性设置的两个实例。应对这一挑战的最佳方式是尽可能实现配置管理的自动化，以便安全工具（而不是人员）提供保护，帮助开发人员和 DevOps 团队更加安全地配置容器和 Kubernetes。在以下风险中，您最担心的是哪个容器和 Kubernetes 环境？配置不当/暴露漏洞攻击不合规46%28%16%9%内容摘要安全问题阻碍创新容器策略责任依旧分散DevSecOps 得到大规模采用配置不当是首要问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全9安全问题57%的受访者最担心容器生命周期中的运行时阶段运行时有时也称为 Day 2

16、 运维或部署后阶段，是企业最为担心的容器生命周期阶段。这种担心似乎与直觉相悖，因为绝大多数受访者认为配置不当是最大的安全风险来源，且发生配置不当的次数比任何其他类型的安全事件更为频繁。然而，需要考虑到，运行时安全问题通常是由构建或部署阶段的安全失误（如配置不当）引起的。此外，只有应用在生产环境中运行时，才可能感受到构建或部署阶段安全失误的任何负面结果。事件响应是安全防护的一个重要方面，在运行时也更加复杂。最后，运行时发现的安全问题，其修复代价也更加高昂。综合以上，就更容易理解运行时安全担忧排名升高的原因了。内容摘要安全问题阻碍创新容器策略责任依旧分散DevSecOps 得到大规模采用配置不当是

17、首要问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全10内容摘要安全问题混合云部署面向大型企业的策略红帽 OpenShift安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全混合云部署大型企业首选混合云部署纯云策略的讨论热度很高，但单云或多云提供商的实际部署与企业的规模高度相关。规模较大的企业（1,000 名员工以上）推崇采用混合方法来运行容器化应用（42%），而规模较小的企业则偏爱单云策略（46%）。虽然混合模式依旧是企业和其他大型组织的主导方法，它们需要一致的安全性和合规性。您在哪里运行容器

18、？我们的数据中心/本地21%29%42%8%27%46%23%4%云提供商混合（本地+云提供商）多个公共云多于 1,000 名员工少于 1,000 名员工11混合云部署红帽 OpenShift，混合云部署的领导者由于混合云部署是大型企业中运行容器化应用最流行的模式，我们希望了解公司如何在混合模式下进行部署。所有在混合环境里运行容器化工作负载的受访者中，有一半使用红帽 OpenShift 管理他们的容器和 Kubernetes。公共云提供商的技术产品的热门程度与平台总体受欢迎程度曲线相似，受访者中有 37%使用 AWS Outposts，24%使用 Google Anthos，另有 17%则使用

19、 Azure Arc。VMware 和 Oracle 的混合产品落后于同行，分别有 9%和 7%的受访者使用。您是否使用任何解决方案进行混合和多云 Kubernetes 部署？（可多选）红帽 OpenShiftAWS OutpostsGoogle Anthos客户 Oracle Cloud50%37%24%7%17%Microsoft Azure ArcVMware Tanzu9%内容摘要安全问题混合云部署面向大型企业的策略红帽 OpenShift安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全12安全防护用例Kubernetes 安全防护热门用例K

20、ubernetes 安全防护用例横跨整个应用开发生命周期，企业期待安全解决方案能够在每个阶段保护容器和 Kubernetes。这些功能涵盖 DevOps 和安全活动，强调在容器和 Kubernetes 安全平台中需要广泛和深入的功能。如此高的比例还突出了这样一个事实：保护 Kubernetes 和容器需要开发、运维和安全团队的参与。受访者认为运行时威胁检测/响应、配置管理和镜像扫描/漏洞管理是有待解决的三个最重要的 Kubernetes 安全防护用例，分别被 69%、68%和 65%的受访者认为是“不可或缺”的功能。您会如何对以下 Kubernetes 安全功能重要性进行排序？运行时威胁检测/

21、响应配置管理镜像扫描/漏洞管理可视性合规网络分段不可或缺锦上添花无足轻重69%26%6%68%65%27%29%5%6%60%36%4%55%39%5%53%42%5%内容摘要安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全13开源安全防护工具Open Policy Agent（OPA）和 KubeLinter 是 Kubernetes 安全性方面使用最广泛的两个开源解决方案。除了商用 Kubernetes 安全产品外，受访者也依赖多款开源安全工具来保护他们的云原生应用。KubeLinter 是面向 Kubernetes 的一款开源

22、 YAML 和 HELM Linter 工具，有 36%的受访者使用了这款工具，而 29%表示他们使用 OPA 来保护 Kubernetes 安全。客户可以选择丰富的开源安全工具，我们的调查结果显示，没有哪款开源安全工具垄断 Kubernetes 安全市场。近四分之一的受访者也使用 Kube-bench、Kube-hunter 和 Falco。您将哪些开源工具用于 Kubernetes 安全？（可多选）KubeLinterOpen Policy Agent（OPA）Kube-benchKube-hunter36%29%24%19%19%FalcoTerrascan其他CheckovClaire

23、17%16%9%9%内容摘要安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全14安全性改进提示改进安全性的 4 点提示 当安全性被忽视时，企业没有确保构建、部署和管理云原生环境的安全性，从而将快速开发和发布应用这一核心优势置于风险之中。我们的调查结果表明，构建和部署阶段发生的情况对安全性有重要影响，企业中普遍存在配置不当和漏洞恰恰突显了这一点。因此，安全必须提前细微地嵌入到 DevOps 工作流中，而不是在应用快要部署到生产中时才“匆忙启动”。使用 Kubernetes 原生安全架构和控制。Kubernetes 原生安全使用该环境内

24、丰富的声明性数据和原生控制，这提供了几个关键的安全优势。分析可用的 Kubernetes 声明性数据可提高安全性，并可基于风险洞察配置管理、合规性、分段和 Kubernetes 特定漏洞。使用相同的基础架构及其控制进行应用开发和安全防护，可减少学习曲线，并更快地支持分析和故障排除。它还能够消除运营冲突，办法是保证安全获得与 Kubernetes 扩展到基础设施相同的自动化和可扩展性有利条件。安全防护应当尽早启动，并且覆盖从构建/部署到运行时整个生命周期。长期以来，安全工作一直被视为一种业务阻碍，尤其是对开发人员和 DevOps 团队来说，核心任务是快速交付代码。有了容器和 Kubernetes

25、，安全工作应该成为业务加速器，帮助开发人员从源头为其资产构建强大的安全性。寻找一个容器和 Kubernetes 安全平台，该平台应将 DevOps 最佳实践和内部控制包含在配置检查之中。还应评估 Kubernetes 本身安全态势的配置，以便开发人员专注于功能交付。12内容摘要安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全15安全性改进提示需要能够在混合环境之间移植。由于大多数公司在本地和公共云环境中（有时在多个云中）部署容器，因此无论您的资产在哪里运行，都必须始终如一部署安全工具。Kubernetes 就是基石，让它成为您的事实

26、来源、执行点以及通用能见度层，这样您就拥有了一致的安全性。Kubernetes 托管服务可能会提高公司采用 Kubernetes 的效能，但要注意被锁定于云提供商特定的程序和服务。在 DevOps 和安全团队之间搭建桥梁，将开发人员转变为安全防护用户。鉴于大多数公司都希望 DevOps 运行容器安全平台，安全工具必须能够帮助桥接 DevOps 团队和安全团队。为了行之有效，平台必须具有能在基于容器化的 Kubernetes 环境中正常工作的安全控制，还应适当评估风险。告诉开发人员修复通用漏洞评分系统（CVSS）分数为 7 或更高的所有 39 个已发现漏洞是低效的行动。帮助开发人员识别该漏洞暴露

27、的三个部署，并找出存在风险的原因，这才能大幅改善您的安全态势。34内容摘要安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全16关于受访者关于受访者Kubernetes 服务92%的受访者使用 Kubernetes（87%用于生产工作负载），其中 Amazon EKS、红帽 OpenShift 和自助式 Kubernetes 是三种最受欢迎的 Kubernetes 服务。您是否使用 Kubernetes 进行容器编排？您使用哪个 Kubernetes 平台来协调容器？（可多选）您是否在 Kubernetes 上运行任何生产工作负载？5

28、0%Amazon EKS44%Kubernetes（自助式）29%红帽 OpenShift28%Google GKE22%Azure AKS15%Rancher/SUSE7%VMware Tanzu6%IBM Cloud Kubernetes Service2%Mirantis Container Cloud1%D2IQ Kubernetes Platform87%是13%否92%是8%否内容摘要安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者Kubernetes 服务常见痛点和边缘部署技术产品核心统计数据红帽 Kubernetes 高级集群安全17关于受访者Kubern

29、etes 安全供应商常见痛点内部人才欠缺和误报太多是市面上 Kubernetes 安全解决方案的最常见痛点。内容摘要安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者Kubernetes 服务常见痛点和边缘部署技术产品核心统计数据红帽 Kubernetes 高级集群安全您当前 Kubernetes 安全解决方案的最大痛点是什么？（可多选）30%缺少内部人才，无法发挥其全部潜力27%没有解决方案24%错误警报（警报疲劳）过多24%整个应用生命周期未得到保护20%太难使用，无法实施到我们的系统中19%安全产品过多17%不能应用于我们采用 Kubernetes 的所有环境中16%

30、减慢了开发速度7%未实现承诺的功能（雾件）边缘部署将近半数受访者在边缘位置运行容器。49%是44%否7%我不知道18关于受访者其他云原生数据除代码存储库和容器镜像仓库外，新兴云原生技术依旧处于早期采用阶段。容器运行时技术Docker 运行时引擎仍然占主导地位，容器远远落后，但正在逐渐拉近距离。87%Docker36%容器17%CRI-O3%Kata 容器2%未知4%其他我不知道不感兴趣正在调查正在试点生产6%4%4%14%15%代码存储库容器镜像仓库Kubernetes 原生 CI/CD 工具（Tekton、Argo 等）无服务器功能即服务（Lambda、Azure Functions 等）服

31、务网格（Istio、Linkerd、Consul 等）Open Policy Agent（OPA）3%15%13%63%16%14%61%9%31%13%33%8%14%25%19%34%8%13%32%16%30%8%40%15%22%31%13%29%14%13%内容摘要安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者Kubernetes 服务常见痛点和边缘部署技术产品核心统计数据红帽 Kubernetes 高级集群安全19关于受访者核心统计数据行业8%教育1%娱乐18%金融服务/保险9%医疗保健5%制造3%媒体47%技术8%其他公司规模25%110026%1011,

32、00015%1,0015,00010%5,00110,00024%10,001+职能工作岗位21%安全10%合规/风险38%运维24%产品开发/工程8%其他21%10%38%24%8%25%26%15%10%24%8%8%18%9%5%3%47%1%内容摘要安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者Kubernetes 服务常见痛点和边缘部署技术产品核心统计数据红帽 Kubernetes 高级集群安全20红帽 Kubernetes 高级集群安全内容摘要安全问题混合云部署安全防护用例开源安全防护工具安全性改进提示关于受访者红帽 Kubernetes 高级集群安全进一步

33、了解用于 Kubernetes 的红帽高级集群安全防护用于 Kubernetes 的红帽高级集群安全防护是 Kubernetes 原生安全平台，能够在您使用容器的过程中保护您的应用进行构建、部署和运行。随着环境更加依赖于自动化，我们的平台将帮助您在越来越复杂的环境中实现安全性操作，跟上 DevOps 的速度。Kubernetes 原生安全具有以下关键优势。最大限度地降低运营风险：使用 Kubernetes 原生控制来降低威胁并实施安全策略，从而最大限度地降低应用的运营风险，让您的安全团队与 DevOps 保持步调一致。降低运营成本：减少时间、精力和人员方面的总体投入，用共同的事实来源简化安全分析、调查和修补。提高 DevOps 工作效率：为开发人员提供可操作且内容丰富的安全指示，并嵌入到现有的、可提高开发人员速度的工作流程和工具中，从而加快创新步伐。已准备好将红帽 Kubernetes 高级集群安全运用于实践？获取针对您的业务和需求量身定制的个性化演示。获取演示 2022 年红帽版权所有。红帽、红帽企业 Linux、红帽 logo 和 OpenShift 均为红帽在美国和其他国家/地区的商标或注册商标。Linux 是 Linus Torvalds 在美国和其他国家/地区的注册商标。