云原生安全白皮书中文版

鸣谢中文译者：@rootsongjc、@N3erox0、@cafra、@aiaicaow、@hbrls、@losery、@knwng、@babysor、@gtb-togerther、@dwctua。

参考文献：CNCF Security Whitepaper v1.1

索引

[TOC]

执行摘要

宗旨

整个技术行业正在向"云原生"的开发和部署模式转变，相关的技术、产品、标准和解决方案等生态系统也在不断扩大，这对于决策者来说，面对新的复杂设计，如何跟上这个步伐将是个巨大的挑战。尤其对于 CISO 的角色，在这个高速变化的环境中，同时肩负着阐明业务价值主张的责任。云原生安全也非常鼓励与现行的其他实践结合，如 scrum 敏捷、DevOps 等工作流程，以便于更好的改变和加速原有的处理模式。

问题分析

随着技术的进步，我们所处的网络环境正日益复杂，安全风险也不断升级。传统基于边界的安全防护机制，如防火墙等，在云原生的场景下很难面面俱到。因此，如果只关注云原生带来的开发和部署的敏捷性，我们或将直面安全风险。为更好保护我们的应用，我们需要一些新的安全方法，更接近于基于元数据或属性来识别动态工作负载（如 SDP 软件定义边界提供了一种实现思路）。这类方法可以更细粒度的识别和保护工作负载，以满足云原生应应用快速扩展、弹性伸缩的特性以及不断变化的外界环境威胁。

这些模式的转变，需要在应用安全生命周期中采用更自动化和安全的架构设计（如零信任）。实施安全策略的过程中，将受到到组织内的多个利益相关方的影响，比如可能会影响开发和运维人员的生产力。成功的安全实施需要考虑在安全与效率间取得平衡。因此，云原生应用仍会经历研发、分发、部署和运维等环节，研发模式决定了新的安全机制的实施空间，而安全机制可以有效地实现应用的安全目标。

云原生开发可以采用不同的方式来建模，来构成应用开发的生命周期，研发、分发、部署、运行态是其中必不可少的要素之一。云原生安全与传统安全方法的最大不同在于，云原生安全需要有一种强有力的机制，更柔和的嵌入方式，来确保安全措施在不同的环节中有效实施。而不能像传统安全方法一样在应用开发生命周期的末尾，通过分散且粗暴的方式进行干预管理。

同时，我们必须注意到，概念、工具和防护措施的使用和整合需要时间推行，同时需要进行长期的意识教育和培训。否则这些概念、工具和防护措施的采纳和实施可能不会持久，甚至可能出现倒退。

生命周期阶段

开发

云原生安全强调在应用程序生命周期的早期引入安全工具，通过安全测试尽早识别合规问题和错误配置等，尽早发现安全问题。具体实现方法就是通过在研发流程中设置安全闸，要求安全问题在流入下一环节前被处置解决。就像处理流水线中的其他问题，如 BugFix、CI Failures 等问题一样，可以尽量缩短问题的修复时间，更好地实现持续改进。

在概念上来说，云原生安全与研发过程密不可分。SaaS 应用的 12-factor 设计原则的一些理念与云原生安全不谋而合；而传统的安全三元素 CIA（Confidentiality, Integrity 和 Availability），也在云原生安全中被充分应用，如对工作负载的完整性保护，与 I (Integrity) 完整性保护相对应。基础设施即代码 (Infrastructure as Code, 简称 IaC) 也与云原生的实践紧密相关。这些方法和原则，都强调通过早期集成安全检测，以确保对过程的控制，使其按预期运行。通过早期检测的预防性成本，降低后续的修复成本，提升了安全的价值。

分发

在能够实现更快软件迭代的模型中，软件供应链的安全显得尤为关键。云原生应用生命周期中的分发阶段不仅需要包括验证工作负载本身的完整性的方法，还需要包括创建工作负载的过程和操作手段。这一挑战由于使用开源软件和第三方运行时镜像以及各种依赖层而被放大，但这些使用和依赖又是不可避免的、实用的和持续的

对于软件生产周期流水线中产生的工件（如容器镜像），需要进行持续的自动扫描和更新来确保安全，防止漏洞、恶意软件、不安全的编码和其他不安全的行为。在完成这些检查后，更重要的是对产品进行加密签名，以确保产品的完整性及不可抵赖性。

部署

在整个开发和集成发布阶段，应对候选工作负载的安全性进行实时和持续的验证，如，对签名的工件进行校验，确保容器镜像安全和运行时安全，并可验证主机的适用性。安全工作负载的监控能力，应以可信的方式监控日志和可用指标，与工作负载一同部署来完善整体的安全性。

运行时

云原生环境在设计时就要考虑策略执行和资源限制的功能。工作负载的运行时资源限制，如 Linux 内核 cgroup 隔离，是限制性和可观察性在云原生环境中，与应用开发相结合的一个例子。云原生运行时环境本身可以分解成多个不同的组件，它们相互关联并有各自的安全考量 1，如硬件、主机、容器镜像运行时、编排。

在云原生运行时环境中，应用程序的微服务架构已被全球各行业和组织采用。应用程序通常由多个独立和单一职责的微服务组成，容器编排层使得这些微服务通过服务层抽象进行相互通信。确保这种相互关联的组件架构安全的最佳实践，包括以下几点：1. 只有经过批准的进程能在容器命名空间内运行；2. 禁止并报告未经授权的资源访问；3. 监控网络流量以检测恶意的活动。服务网格是另一种常见的服务层抽象，它为已经编排的服务提供了整合和补充功能，而不会改变工作负载软件本身（例如，API 流量的日志记录、传输加密、可观察性标记、认证和授权）。

结论

云原生具备大规模、按需付费的特点，同时具有高可用性、高可靠、高弹性和冗余性。如能在组织中战略性的落地云原生安全，可确保客户和开发人员以他们期望的速度、安全地访问所需资源。安全本身是一个跨学科的领域，现在仍不能从开发生命周期中剥离出来，安全也并不是单纯由技术驱动。因此开发者、运营商和安全人员需要彼此配合，交流合作，以伙伴的关系共同持续推动该领域的发展。也和其他任何技术创新一样，云原生安全及其社区的兴盛取决于人们共同的心血与付出。

介绍

本文档旨在为组织以及技术领导者提供对云原生安全的清晰理解，及其如何在参与整个生命周期流程中使用和评估安全相关的最佳实践。云原生安全是一个多目标和多限制的复杂问题范畴，会跨越许多专业技术和实践领域。软件生命周期中 Day 1、Day 2 的绝大多数操作都会涉及到从身份管理到存储解决方案的安全技术或领域。然而，云原生安全所涵盖的内容远不止这些领域；它是个关于人的广义问题范畴，包含个体、团队和组织。它应该成为人和系统在深度使用甚至改造云原生应用技术过程的一种机理、流程和理念基础。

目标受众

我们的目标受众是希望建设安全的云原生技术生态系统的私营企业、政府机构或非营利组织的首席安全官 (CSO)、首席信息安全官 (CISO) 或首席技术官 (CTO)，也包括组织内的其他相关人员，包括负责设计和实现安全云原生产品服务的项目经理、产品经理、工程师经理和架构师等。除此之外，任何对云原生安全有浓厚兴趣的人都可以参考本文档。

云原生目标

容器和微服务架构的采用和革新带来了不少挑战。在现代化组织中，减少网络安全漏洞的需求优先级已经成明显趋势地攀升。同时，随着围绕云应用的创新加速，新的威胁状况也在增加。安全领导层需要通过采取预防、检测和应对网络威胁等措施、满足严格的合规要求，来完成他们身上背负的“保护包括人力 4 和非人力资产”任务。然而，有个常见的旧说法，指责这些安全措施阻碍了 DevOps 团队的速度和敏捷性。因此，安全领导层必须搭建起更紧密的集成和互相理解的通道，在为 DevOps 团队赋能更多的同时，使得其能有共同抵御网络风险的责任心。

我们希望确保整个行业能重视和落实安全实践，并整合到整个现代化应用开发生命周期中，所以需要分享组织所需的安全云原生采用模式和架构。强调安全架构与安全领导层的协同作用，并对齐组织的安全目标，包括漏洞管理、零信任、云安全和 DevSecOps 等方面，是我们的首要任务。

本文档所描述的任何概念不会对某一特定服务或组件产品有倾向或推荐，而是普遍适用的。

本文档不是用于提供有关安全概念或云计算概念通识教育的，也不推荐具体的技术或工具；但是，可能会引用解决所讨论主题的技术或工具的例子。

除了本文档中的建议外，关于数据保护和隐私监管规定（如 GDPR、PCI DSS）相关的安全处理实践，是需要读者进行额外的针对性考虑。对于这些实践，我们建议读者通过其他适当的专业咨询资源去学习有关相对应的技术控制和合规风险事项的指导。

文档前提

CNCF 已经在 CNCF 技术监督委员会 (TOC) 的 GitHub 资源库中对云原生进行了定义，本文档并不试图改变这一定义或对其进行扩展。

随着云原生应用和现代软件开发方法的不断发展，构成有效的云原生栈的技术将随着时间的推移而不断变化。这种不断变化的栈可以在丰富的云原生全景图中查看。

本文档中的术语"工作负载 workload"涵盖了已经或将要开发、维护、分发或部署到基于云的运行时环境的任何产品、项目、应用和系统。

云原生层次模型

图一

云原生技术栈由基础设施层、全生命周期管理、运行环境组成。云原生技术栈可以适用于不同的云计算服务模式：IaaS、PaaS、CaaS 和 FaaS。每种服务部署模式都提供了额外的抽象，以简化云原生环境的管理和操作。由于这些服务模式中的一些模型是众所周知的，并已使用多年，我们将重点关注云原生特有的模型。

CaaS（容器即服务，Containers-as-a-Service) 模式允许用户通过利用基于容器的虚拟化平台、应用编程接口 (API) 或管理页面来管理容器、应用和集群。CaaS 帮助用户构建可扩展的容器化应用，将安全策略嵌入到配置文件中，并在私有云、企业内部数据中心或公有云平台上运行。CaaS 有助于简化构建容器的过程。通过微服务编排和部署，它帮助企业更快地发布软件，并允许在混合云环境之间进行移植，从而降低基础设施投入以及运营成本。CaaS 模式可以帮助企业简化容器管理，同时让企业可以选择只为自己想要和使用的 CaaS 资源付费，从而节约成本。CaaS 以容器为基本资源，而对于 IaaS 环境，则使用虚拟机（VM）和裸金属主机。

FaaS（函数即服务， Functions-as-a-Service ) 是另一种云原生部署模式，是一种允许企业用户通过可执行代码来响应事件的云服务，这种模式用户无需构建和启动微服务相关的复杂基础设施。在云端托管一个软件应用，通常需要配置和管理一个虚拟环境，管理操作系统和网络组件等。通过 FaaS，物理硬件、虚拟机操作系统和 Web 服务器软件管理都由云服务提供商自动处理。从而使用户能够专注于微服务代码中的各个功能，同时为使用的资源付费，并利用云计算提供的资源金进行弹性伸缩。

全生命周期管理

云原生环境下的生命周期管理是指云环境中管理、监控和弹性扩展工作负载的技术、实践和流程。如图 1 所示，生命周期管理由四个连续阶段组成：开发、版本分发、部署和运行。每个阶段都在安全的工作负载执行的基础上推进了前一个阶段的工作。

全生命周期管理过程

管理供应链和制定适用的安全基准对于安全实施至关重要。

供应链

各组织有责任确保其正在使用的的应用程序的供应链在全生命周期管理过程中接受安全扫描。供应链安全可分为两部分：为创建应用程序使用的工具和服务（如开发工具）的安全，以及构成应用程序本身的组件（如库、依赖项和镜像）的安全。供应链的实现根本在于供应链本身的完整性是可验证的，软件开发中，供应链产生的组件需要进行签名来验证来源。除此之外，上游的依赖包将不可避免地包含安全漏洞，所以组织在使用第三方依赖时必须谨慎。验证所使用的第三方软件包的真实性和完整性，对于确保依赖项符合预期，不带来额外的安全威胁至关重要。

云原生应用的一个主要特征是具备可复用性，这些应用可以使用开源软件包和通过开源镜像仓库构建和分发的容器镜像来实现该特征。因此，开发人员、运维人员和安全人员必须确保其应用程序中的组件和依赖项不包含已知的恶意软件和漏洞。容器镜像中的恶意软件是攻击者针对运行时环境中进行攻击的一个主要手段 5 。对 CI 管道、镜像仓库中的容器镜像和组件包按企业规范实现定期的漏洞扫描是至关重要的。

利用这些方法可以实现可验证的、安全的软件分发和持续的安全运营。企业在工作负载创建的 pipeline 中纳入漏洞扫描，能够使开发团队及时的进行反馈，并有可能进一步阻止不安全或含有漏洞的版本更新被分发和部署。定期扫描软件还可以升级现有软件中新发现的漏洞。

安全基线

利用安全基线（如 NIST Application Security Container Guide、Center for Internet Security(CIS)、NIST Security Strategies for microservices、OpenSCAP) 为开发团队和组织提供创建"默认安全"的工作负载的指南。采用和实施这些基准，使团队能够对使用安全基线进行加固的工作负载进行测试。然而，这些安全基线没有考虑到实际企业的业务场景和实际需求。安全从业人员应将这些基线作为指南而不是清单来执行。

接下来的几节将详细分析将安全嵌入到整个应用程序生命周期中的影响，在这个过程中使用的工具、机制和最佳实践。

开发

图二

云原生应用的安全需要在应用的整个生命周期中进行管理。开发阶段是这一周期中的第一个阶段，它实现了基础设施即代码（IaC）、应用程序和容器等组件的创建，这些组件将用于部署和配置云原生应用程序。这些组件已被证明是许多可在运行时利用的攻击向量的来源。接下来的几节将详细介绍在此阶段需要建立的各种安全工具、流程和检查，以大幅减少在运行时部署的应用程序的攻击面。

开发中的安全检查

开发阶段的安全强化是应用程序部署中的关键组成部分。这意味着必须在软件开发的早期就引入安全要求，并以与其他任何要求相同的方式对待安全要求。这些要求通常基于围绕风险和合规性的业务需求。在早期阶段解决这些需求可防止在生命周期后期重做工作，这会减慢 DevOps 流程并增加总体成本（5）。DevOps 团队还必须利用专门构建的工具在部署这些应用程序之前识别安全性错误配置和漏洞。同样重要的是，这些工具可以无缝集成到 DevOps 团队利用的现有和熟悉的工具中，以补充敏捷性而不妨碍安全性。例如，工具需要在开发人员 IDE 内或发出“拉取请求”时，以代码模板以及应用程序清单的形式执行基础结构的扫描，并提供丰富，上下文相关的安全信息，这些信息可以在早期，快速，轻松地实施。开发管道。采用这些步骤可确保不存在已知漏洞或高风险配置。云原生组件应由 API 驱动，以允许复杂的调试工具与依赖编排器的已部署原始工作负载进行交互。

团队应部署专用的开发，测试和生产环境，以便为基础结构和应用程序开发人员提供隔离的环境，以开发，测试和部署系统和应用程序，容器基础镜像，虚拟机模板镜像以及非功能性测试。一些组织可能会发现利用金丝雀部署，蓝绿色或红黑色部署以及其他部署模型可以提高动态和交互式测试的可行性，并提高可行性。

测试开发

开发人员，操作员和安全人员应针对关键业务，具有高威胁特征，易受频繁更改或具有错误历史记录的代码和基础结构构建测试。威胁建模可以识别高风险和高影响力的代码热点，针对这些热点开发测试可提供高投入回报（ROI）。测试可能包括部署，操作系统，基础架构和数据库强化，应用程序测试（静态和动态源代码测试，容器配置），集成或系统测试（接受应用程序和基础架构组件及其交互）以及冒烟测试（部署后）检查实时系统）。测试作者应该可以访问全面的开发和测试环境，从而使他们能够执行快速的测试开发，同时减少持续集成（CI）反馈循环。系统测试套件应可供作者在本地以及内部运行。

代码审查

对工作负载或已部署工作负载的基础结构进行的细微更改可能会产生深远的安全后果。为了减轻意外后果的风险，鼓励团队在将先前的更改合并到代码库中之前（例如，在 git 工作流中实现拉取请求）在进行代码审查时使用“四眼”原则。

分发

图三

“分发”阶段负责使用镜像定义和规范来构建工件的下一阶段，例如容器镜像，VM 镜像等。在现代的持续集成和持续部署范式中，“分发”阶段包括了系统的应用程序测试，以识别软件中的错误和故障。但是，采用开放源代码和可重用软件包会导致将漏洞和恶意软件合并到容器镜像中。因此，必须结合安全方面的步骤，例如扫描镜像以获取上述威胁，以及验证镜像的完整性以防止篡改。接下来的段落将详细介绍安全最佳实践，这些最佳实践可帮助开发人员和操作员识别并保护容器镜像免受威胁，以及可确保整个 CI / CD 管道和基础结构安全的技术和工具。此外，如果期望或需要保密，组织机构可能希望对软件构件进行加密。

如果由于被破坏或其他事件而使软件组件变得不可信，团队应撤消签名密钥以确保阻断风险。

构建流程

持续集成（CI）服务器应被隔离，并仅限于具有相似安全性或敏感性的项目。需要提升特权的基础结构构建应在单独的专用 CI 服务器上运行。构建策略应在 CI 流程中以及编排器的准入控制器中执行。

供应链工具可以收集并签署构建流程的元数据。然后，后续阶段可以验证签名，以验证先决条件工作流阶段是否已运行。

读者应确保持续集成和持续交付（CD）基础结构尽可能安全。例如，应优先考虑安全更新的尽快安装，并应通过使用硬件安全模块（HSM）或凭据管理器来保护加密密钥不被泄露。

镜像扫描

扫描容器镜像是在整个生命周期中保护容器应用程序的重要组成部分。在将镜像部署到生产之前，在持续集成工作流中进行扫描至关重要。集成此功能可确保开发人员，操作员和安全专业人员获得有关所有已知漏洞的详细信息，以及诸如严重性，CVSS 分数和缓解/修补程序的可用性之类的详细信息。将容器镜像的漏洞扫描与管道合规性规则相结合，可确保仅将充分打过补丁的应用程序部署到生产环境中，从而减少了潜在的攻击面。扫描容器镜像还有助于识别在从开源镜像存储库合并的开源软件包或基础镜像层中是否存在恶意软件。容器镜像扫描的使用可为团队提供了漏洞或恶意软件的真实情况，并不能提供针对漏洞或恶意软件的预防措施。组织机构在使用镜像扫描，设置基于扫描结果的可行性措施和执行合规性规则时应持审慎态度。

镜像强化

容器镜像构成了构建工作流的第一级输出。因此，它们必须包括安全性强化功能，该功能考虑了要缓解的威胁，同时允许在运行时阶段进行一些即时配置以适应较大生态系统。

针对这阶段安全强化的目标，应评估以下问题：

• 应该将执行环境限制为特定用户吗？

• 资源的访问权限应该受到限制吗？

• 应该在内核级别限制进程执行吗？

容器应用清单扫描

应用程序清单描述了部署容器化应用程序所需的配置。如基准部分中所述，指南和建议（例如 NIST 800-190 出版物）建议了最佳安全实践和应用程序容器的配置。因此，在 CI/CD 工作流中使用工具来扫描这些应用程序清单以识别可能导致不安全部署状态的配置至关重要。

容器应用清单加固

至于容器镜像，容器应用的清单强化可以在构建以及运行时注意和实现。

在保证安全的目标方面，应评估以下问题：

运行时执行生态系统应该遵守哪些最小约束条件？

测试

云原生应用程序应和传统应用程序一样，遵循相同的质量测试套件和标准。包含：清洁代码，采用测试金字塔，应用程序安全测试及扫描包括：静态安全测试（SAST），依赖分析和扫描，动态安全测试（DAST）（如模拟测试），应用工具，以及向开发人员提供完整的本地测试环境。自动测试结果应该能和需求挂钩，体现出开发人员和工具的预期和结果是否一致，以便向安全和合规团队提供实时安全保证。

对于已经发现的安全 bug，（例如错误的防火墙或路由规则），要进行根本原因分析，如果认为此类问题很有今后还可能会再次发生，开发人员应该编写对应的自动化测试代码，防止问题再次发生。在测试失败时，团队根据反馈进行 bug 修复。从而在下一次合并时，保证测试通过（假设已经修正）。这样可以避免将来代码变动引发新的问题。

基础设施的单元测试是预防性控制，把在基础架构即代码 (IaC) 的配置中定义的实体和输入，作为测试目标。已建基础设施的安全测试是一种检测性控制手段，并融合保证、历史回归和异常配置检测（如防火墙规则对外开放、过度授权的 IAM 策略、未认证的端点等）功能。

综合测试套件可以强化基础设施和工作负载，以便其随着系统的成熟逐步强化。在构建过程中应该有验证系统强化的测试，并在部署时也应执行，以评估整个生命周期中可能发生的任何变化或回归。

静态分析和安全测试

对 IaC、应用程序清单和软件代码的静态分析，应该包括过滤、识别错误配置和漏洞扫描。IaC 代码应受到与应用程序工作负载相同的流水线策略控制。

IaC 越来越受欢迎，在企业中的部署迅速增加，以部署云和容器基础设施。因此，这些模板中的不安全配置可能导致其成为被攻击目标。

在部署应用程序和基础设施组件之前，应使用自动化工具扫描这些模板，以发现不安全的配置和其他安全控制漏洞。需要注意的关键错误配置包括：

应用程序清单中指定的镜像中包含的漏洞。
配置设置，比如可以升级权限的容器。
识别可能危及系统的安全上下文和系统调用；
资源限制设置

动态分析

已部署的基础设施的动态分析，应包括检测 RBAC（基于角色的访问控制）和 IAM（身份和访问管理）的配置变化，验证预期的网络攻击操作，并确保 SOC（安全运营中心）能够在专用测试环境中检测到异常行为，为产品配置警报。尽管动态分析被认为是测试的一部分，但通常是在测试环境执行分析的。

安全测试

应用程序和基础设施的自动安全测试应成为安全小组的一个必备重点。测试套件应持续更新，以复制与组织威胁模型相匹配的威胁，并可随着系统的迭代，重复进行安全回归测试。自动化安全测试提高了安全性和发布速度，原因是其取消人工安全校验，如在单一检查点进行验证和人工控制实施，耗时且不充分。自动安全测试还可以通过直接执行一些威胁测试，来证明按需控制的有效性，从而提高系统的安全性，并实时遵守任何内置的合规性要求。

工件和镜像

仓库隔离

由于使用的开放源码组件往往是从公共来源中提取的。各组织应在其流水线中，创建不同阶段的仓库。只有已授权的开发人员才能访问公共仓库和拉动基础镜像，然后将其存储在内部仓库中，以便在组织内部广泛使用。此外，还建议有单独的私有仓库，用于保存每个团队或小组的开发工件，最后还有一个暂存或预生产仓库，用于准备生产的镜像。这样可以对开源组件的来源和安全性进行更严格的控制，同时可以对 CI/CD 的各个阶段进行不同类型的测试。

对于任何在用的仓库，必须通过专门的认证和权限模型实施访问控制。对所有仓库的连接要采用相互认证的 TLS（以及基础设施内部的其它连接）。

签名、信任和完整性

在构建时对镜像内容进行数字签名，并在使用前对签名数据进行验证，可以保护该镜像数据在构建和运行之间不被篡改，从而确保组件的完整性和来源。首先必须要有流程确认组件是经过审批的。信任确认还包括验证组件是否具有有效的签名。在最简单的情况下，每个组件都可以由一个签名者签名，以表明组件经过了单一的测试和验证过程。然而，软件供应链在大多数情况下比较复杂，创建一个组件依赖于多个验证步骤，因此依赖于实体的信任集团。例如：

容器镜像签名：对容器镜像清单签名的过程。
配置签名：配置文件的签名，即应用程序配置文件：

最常见的案例是 gitops 相关操作访问，此过程中会验证并检查其配置。

包签名：对组件包（如应用程序包）进行签名。

对于通用软件组件，如软件库或 OCI 组件，在这些打包文件上签字表示它们的来源是经组织批准使用的。这些验证对于确保只允许使用经授权的打包文件至关重要。强烈建议仓库要求相互认证，以便对仓库中的镜像进行更改或向仓库提交代码。

加密

对容器镜像进行加密，从而保证镜像内容的机密性。加密后，以确保它们从构建到运行前都是密文态。当加密镜像分发后受到破解，制品库中存储的镜像仍然是加密的，这有助于保护商业机密或其他保密材料等。

容器镜像加密的另一个常见用途是容器镜像授权的增强。当镜像加密与密钥证明管理和/或授权、认证发布等相结合时，可以要求容器镜像只能在特定平台上运行。容器镜像授权也适合保证合规性，例如地理限制、出口管控和数字版权媒体管理。

部署

图四

”部署“阶段负责安排一系列的"执行前"检查，以确保即将部署的应用程序在运行时能符合并遵守本组织的安全和合规性策略。

执行前部署检查

在部署之前，各组织应核实以下几方面是否到位、适用性以及当前状况：

镜像签名及完整性
镜像运行策略（如没有恶意软件或严重的漏洞）
容器运行策略（如无过度权限）
主机安全漏洞和合规性控制
工作负载、应用程序和网络安全策略

可观察性和指标

将可观察性和指标纳入云原生架构，可提供对系统安全的洞悉力，从而使相关的负责人能够解决或缓解各种异常情况；这一领域的工具还可用于信息的收集和可视化。通过对使用行为和启发式分析，运维团队可以检测并将异常值、可疑事件和不明原因的调用及时上报给相关的负责人。人工智能 (AI)、机器学习 (ML) 或统计建模都是用于行为和启发式分析开发的常用工具。

响应和调查

应用程序应该提供有关认证、授权、执行和故障的日志。开发人员应在规划和设计阶段将这些功能纳入其中。当进行调查并需要确定根本原因时，这些要素会提供可循的依据。

取证能力是任何事故应对和缓解活动的组成部分。它们提供证据以确定事件的根本原因，并为任何缓解措施的实施提供反馈。容器环境的短暂性要求更灵活的工具来收集和分析任何证据。将取证能力集成到事件响应计划和程序中，将帮助收集和处理证据，减少确定根本原因的时间，并最大限度地减少损害的风险。

运行环境

图五

运行阶段包括三个关键领域：计算、访问和存储。虽然运行环境取决于开发、分发和部署阶段的成功完成，但运行的安全性取决于前几个阶段的安全实践的有效性。以下各段将详细介绍这些关键组件的安全要求和影响。

计算

云原生计算是一个高度复杂且不断发展的构造。如果没有核心组件使计算利用发生，组织就无法确保工作负载的安全。

考虑到容器为共享主机上的多租户应用程序提供了基于软件的虚拟化，因此使用容器特定的操作系统是非常重要的，这是一个只读操作系统，其他服务被禁用。这有助于减少攻击面。这也提供了隔离和资源限制，使开发人员能够在共享主机内核上运行隔离的应用程序。为了系统安全，建议不要让不同的数据敏感工作负载运行在同一个操作系统内核上。

为了使安全跨越容器平台和服务的所有层级，可以使用基于可信平台模块（TPM）或 vTPM 作为硬件信任的基础。基于硬件的信任链可以扩展到操作系统内核及其组件，以实现可信任启动、系统镜像、容器运行时和容器镜像等的加密验证。

操作系统提供了基本的系统组件，如用于远程连接的加密库和用于进程启动、管理等的内核模块。这些都可能存在漏洞，由于它们为容器提供了底层的计算功能，因此会影响到这些主机上运行的所有容器和应用。同时配置不当的容器也会影响主机内核安全，从而影响该主机上运行的所有容器中的服务。更多信息请参考本文分发阶段内的细节。

编排

任何一个编排系统都有多个组件，这些组件被分成不同的平面，如控制平面和数据平面。有时还需要有一个更高层次的多部署管理构造，负责在几个不同的控制平面上维持状态，这些平面相互独立地共存。

任何编排系统都会受到一些攻击，这些攻击会影响部署的整体安全性和运行时的持续安全性。恶意访问编排系统的 API、未经授权访问和更改 key-value 存储、通过仪表板控制集群、拦截控制平面数据、滥用 API、拦截应用程序数据等都是潜在的威胁领域。对于任何编排系统来说，采用最佳实践和配置强化是很重要的方法来防止其成为被攻击的目标，实例可参考文献 [7] 。同样重要的是监控和检测在运行时对初始配置的任何更改，以确保集群的持续安全运行。其他安全最佳实践，如尽量减少对控制平面的管理访问、职责分离和最低特权等原则，都应该确保贯彻实施。

安全策略

必须考虑你的编排系统的安全特性和各种配置选项，以控制容器运行时可以用来建立容器的安全权限。使用更高层次的策略和监管可以强制执行这些安全防护措施。

资源请求和限制

通过 cgroups 对不同的对象和资源请求进行限制，这有助于防止有意（如 DDos 攻击或加密货币挖矿）或无意（如在内存中读取大文件而不进行输入验证，水平自动缩放以耗尽计算资源）的导致节点和集群的资源被不当的工作负载耗尽。

审计日志分析

审计日志分析是识别和关联系统入侵、滥用或配置不当的最成熟方法之一。审计日志分析和关联的持续自动化对安全团队至关重要，因为云原生架构能够为工作负载生成比传统系统更精细的审计配置和过滤。此外，云原生日志的互操作性还可以进行高级过滤，以防止下游处理中的过载。与传统的日志分析一样，这里最关键的是生成可操作的审计事件，将日志中的数据关联/上下文转化为"信息"，从而驱动决策树/事件响应。

根据预先配置的一套规则，对违反组织政策的行为进行过滤，检测出不合规的违规行为。

为了能够审计使用集群的实体的行为，至关重要的是要启用 API 审计，并对一组特定的 API 组或动词进行过滤，这些 API 组或动词是安全团队、集群管理员或其他研究领域的团队所感兴趣的。立即将日志转发到通过集群级凭证无法访问的位置，也可以击败攻击者通过禁用日志或删除其活动日志来掩盖其踪迹的企图。定期优化报警系统包括：消除误报以避免警报过于频繁导致疲劳，对系统未检测到的安全事件要改善漏报。

控制平面认证和根证书

系统管理员应配置所有控制平面组件之间的通信要使用安全证书进行相互认证。安全证书也需要定期轮换以强化系统安全。安全证书颁发机构 CA 可以是默认的编排系统 CA，也可以是外部 CA。管理员应特别注意保护 CA 的私钥。关于扩展或建立信任的更多信息，请参考本文的鉴权和访问管理部分。

凭证（如密钥）加密

在容器编排或部署时可以使用外部密钥管理系统来管理密钥，也可以直接使用编排系统本地的密钥。当使用本地密钥时，关键是要知道有几种不同的保护方法。

使用外部密钥管理存储 (KMS) 加密
- 利用 KMS 是保护编排系统数据秘密一种安全方式，外部的 KMS 将对数据加密密钥（DEK）进行加密，然后使用 DEK 对保存在 etcd 中的数据进行加密。这种方法还可以将 DEK 缓存在内存中，以减少对外部 KMS 的依赖，并可在创建 pod 时加快解密速度。
编排系统加密管理
- 由编排系统对数据进行加密，同时加密密钥也由编排系统管理（如采用配置文件）。
不加密
- 有些编排系统采用 base64 编码，默认情况下，数据实际以明文保存在 key-value 存储中

使用外部密钥管理系统可以降低使用明文的风险，并降低密钥管理的复杂性。大多数情况下，这些工具都是作为 controller 或 operator 使用，可以在运行时注入密钥，并定期自动轮换而无需人工干预。

容器

运行时

容器的运行时环境需要从进程、文件和网络的角度被监控和保护。只应该允许那些得到许可的功能和系统调用（如 seccomp 过滤器）在容器中执行或被宿主机操作系统调用。容器运行时应该监控和预防对关键挂载点和文件的改变，且对它的配置必须能够预防对二进制文件、证书和远程访问配置的更改。这种配置还必须限制容器只能进行为完成操作所必须的入口和出口网络访问。此外，那些访问恶意域名的网络流量应该被检测并阻止。

微服务和消除隐性信任

作为微服务部署的容器化应用程序的边界就是微服务本身。因此，有必要设定策略，只允许在得到许可的微服务间进行通信。在微服务架构中引入零信任，可以在一个微服务被攻陷时阻止其横向移动，从而缩小影响范围。运维人员应确保他们正在用网络策略等功能，确保一个容器部署内的东西向网络通信只限于授权网络。在 NIST SP 800-204 中初步提供了一些用于微服务的策略，这些之后可能会成为实现安全微服务架构的指南。

对镜像的信任和内容保护

企业可以使用策略代理来强制或控制经过认证和签名的容器镜像，从而能够为运维工作提供映像出处的保证。除此之外，引入加密容器可以保护容器内的敏感源码、方法或数据。

服务网格

服务网格提供了服务之间的连接，增加了流量控制、服务发现、负载均衡、弹性、可观察性、安全等。服务网格可以让微服务把这些功能从应用层软件库中剥离，让开发者专注于差异化的业务逻辑。为了有效地确保云原生环境中服务之间的安全通信，企业应该部署服务网格来消除其 Pod 内部和不同工作负载之间的隐性信任，这些可以通过数据传输时加密来实现。由于传统的三层和四层标识、IP 地址不再能清晰地与工作负载对应，使用服务网格还可以解决身份问题。服务网格不仅提供了网络层的隔离和安全，还提供了保持网络层弹性的能力，如重试、超时，以及各种断路功能。流媒体平台可以通过使用工作负载级别的授权来设置主题或代理的访问规则来提高安全性，从而从服务网格中获益。

值得注意的是，部署服务网格有助于缩小云原生部署的攻击面，并为构建零信任应用网络提供关键框架。

运行时检测

监控已部署的工作负载能够帮助团队验证当前真实的运行状态达到了预期状态。企业不能放弃在环境中进行定期的安全扫描和监控，否则就会使他们的工作负载变成攻击者不受限制的游乐场。应利用那些可以检测、跟踪、汇总和报告来自容器的系统调用和网络流量的工具，来发现非预期或恶意行为。

虽然回归测试和安全测试可以帮助防止已知的、预期的问题转移到生产环境中，但它们不能阻止一切。我们应该对工作负载进行动态扫描，以检测尚未发生过的恶意行为。诸如通过扩展的睡眠命令，在工作负载运行了 X 天之后将 etcd 中的数据外泄之类的事件，在大多数环境中是不被考虑到的，因此不会包括在安全测试中。对于工作负载中可能存在时间或事件延迟木马的问题，只有通过与基线预期行为进行比较才能检测到，这通常是在彻底的活动监控和扫描中发现的。

此外，工作负载在部署时或之后会变得脆弱。企业应持续扫描其环境以检测哪些工作负载现在是脆弱的。了解每个工作负载的组成或资产清单可以帮助组织快速识别漏洞所在。有关这些漏洞的其他信息，如漏洞成熟度和漏洞利用路径，对于确定工作负载的实际风险至关重要，并可帮助企业优先更新有风险的应用程序。

函数

无服务器函数很容易受到各种攻击，因此需要进行适当的保护。进程必须只执行允许列表中明确定义的函数。此外，不应允许函数对关键的文件系统挂载点进行修改。

这些函数必须被限制只能访问被认可的服务，这种限制可以通过网络限制或权限模型中的最低权限来实现。此外，出口网络连接必须由管理员监控，以检测甚至阻止其访问 C&C（命令和控制）服务器和其他恶意域名。还需要监控入口网络连接，以检测和移除那些可用于数据泄露的恶意载荷和命令。例如，可以通过网络监控来检测 SQL 注入攻击。

无服务器函数中存在一些安全威胁，但可供租户使用的控制措施是有限的。这些问题包括有缺陷的身份验证机制和与依赖服务之间不安全的 API 集成等。有一些措施有助于解决这类问题，如确保所有无服务器函数在基于租户的资源隔离环境中和相似的数据类型上运行。然而，由于隔离环境中可用的地址空间有限，这些措施会对性能造成影响。

引入

信任需要被引入到计算节点中，以确保工作负载和配置运行在正确的节点上。引入信任可以确保计算在正确的物理和逻辑位置进行，并能够进行自我认证。这些步骤通常是云提供商所提供服务的一部分，但是有一些方法可以在减少对第三方的依赖情况下进行验证。

存储

云原生存储涵盖了一系列广泛的技术，分为呈现式存储和访问式存储。呈现式存储是向工作负载（如卷）提供的存储，包括块存储、文件系统和共享文件系统。访问式存储是通过应用程序 API 访问的存储，包括对象存储、键值存储和数据库。

存储系统包含一个数据访问接口，该接口定义了应用程序或工作负载如何存储或消费由存储系统或服务持久化的数据。这个接口可以通过访问控制、认证、授权和可能的传输加密进行保护。

存储系统还包含一个控制平面管理接口，一般情况下它是一个受认证和 TLS 保护的 API。通常情况下控制界面只能由编排器或服务代理通过服务账户访问，尽管可能有更细粒度的访问方式。

存储栈

任何存储解决方案都由多层功能组成，这些功能定义了数据应如何被存储、检索、保护以及与应用程序、编排器和/或操作系统进行交互。这些层中的每一层都有可能影响和冲击存储系统的安全性。一个常见的例子是将文件或块持久化到对象存储的文件系统。同样重要的是保护拓扑结构中的每一层，而不仅仅是用于数据访问的顶层。

编排

大多数编排系统将实现各种抽象和虚拟化层，其中可能包括文件系统（如绑定挂载）、卷管理器以及基于编排器策略的用户或组级别的权限管理。与容器化和微服务架构的许多组件一样，保护卷和存储将始终依赖于其他能力的保护。如果用户能够在编排器或容器运行时内将他们的权限提升到 root，他们就会在环境中造成破坏。零信任、最小权限、访问控制和执行的实施是成功保护云原生架构存储安全的关键。

系统拓扑和数据保护

为了保护对存储系统的数据访问路径和分布式拓扑结构中节点内通信的安全，理解系统的存储拓扑结构是关键。

常见的拓扑结构包括所有计算节点访问中央存储服务的集中式模型、将功能分布在多个节点上的分布式模型，以及将应用负载和存储负载结合在相同节点上的超融合模型。系统所使用的拓扑结构决定了对某个特定的、分层安全机制的选择，来保护存储中的数据和在存储位置之间传输的数据。

任何存储系统的一个关键功能是为系统或服务中持久化的数据提供保护。这种保护首先应该能够向被授权用户提供数据，并应作为系统中的一个透明层存在。这就包括了奇偶校验或镜像、纠删码或创建副本等技术。接下来是针对完整性实施保护，存储系统会在块、对象或文件中增加哈希和校验和，主要是为了检测和恢复损坏的数据，但也可以增加一层保护，以防止数据被篡改。

缓存

缓存层通常作为完全独立的系统，为了提高存储系统的性能（特别是文件系统、对象和数据库）的性能而部署的。缓存层需要使用合适的访问控制和安全策略，因为缓存会先于实际存储后端被访问。

数据服务

存储系统通常会实现一些数据服务，通过提供额外的功能来补充核心存储功能，这些功能可以在堆栈的不同层实现，可能包括创建副本和快照（数据的时间点副本）。这些服务通常用于对数据副本进行远程移动，同时必须确保对远程数据使用相同的访问控制和安全策略。

物理层或非易失性层

云原生存储安全并不局限于虚拟的云原生架构，因为云原生功能可以是预置的，甚至虚拟产品也有物理存在。重要的是要记住，存储系统最终会将数据持久化在某种形式的非易失性物理存储上。现代物理存储（如固态硬盘）通常支持安全功能，如根据 OPAL 标准进行自我加密，以及快速/安全的擦除功能。当包含数据的设备需要离开安全的物理位置时（例如出现故障后要返回给供应商），安全擦除是非常重要的。

存储加密

存储系统可以通过数据加密的方法来确保数据的保密性。数据加密可以对传输中的数据或静止状态下的数据实施加密，当在存储系统中使用数据加密方法时，应该确保加密功能是独立于应用实现的。

加密会对性能产生影响，因为它隐含了计算开销，但许多系统上都有加速选项可以减少开销。在选择数据的加密类型时，要考虑数据路径、大小和访问频率，以及任何可能需要使用更安全算法的规定或额外的安全防护。此外，团队在考虑架构的加密需求时，不应忽视对缓存的使用。

加密服务可以提供给传输中的数据（保护网络中的数据）和静止中的数据（保护磁盘上的数据）。加密可以在存储客户端或存储服务器中实现，加密的粒度将因系统而异（例如针对每卷、每组或使用全局密钥）。在许多系统中，传输中的数据是用 TLS 保护的（它的额外好处是通过证书提供了一个认证层，需要注意的是，当可以使用认证协议时，可以同时对客户端和服务端进行认证的双向认证是更被推荐的认证机制）。旧的协议（如 iscsi ）可能更难保证传输中的安全（尽管可以使用更复杂的解决方案，如 IPsec 或加密的 VPN ，但是通常使用 VPN 并不能保证加密）。静止状态下的数据通常使用标准的对称加密算法（如 AES ）进行保护，并可部署特定的加密模式，如用于块设备的 XTS 。

加密功能往往依赖于与密钥管理系统的集成。

持久卷保护

保护对卷的访问对于确保只有授权的容器和工作负载才能使用所提供的卷至关重要。当务之急是为命名空间定义信任边界，以封锁对卷的访问。可以利用现有的或创建新的安全策略，防止容器组访问工作节点上的卷挂载，并确保只有合适的工作节点可以访问卷。尤为关键的是对于有特权的容器应该采取额外的预防措施，因为它们可以访问不同命名空间中的挂载卷。

指定卷的 UID 或 GID 仍然会允许同一命名空间的容器访问，并不能提供数据保护。网络文件系统（NFSv3）假设客户端已经进行了认证和授权，而不进行验证。在实施保护时，必须考虑认证和授权发生在哪里，以及是否存在对这些操作的验证。

组件仓库

仓库应采用各种技术来对 OCI 组件进行签名和确认。同样重要的是，确保缓存和分发工具也提供签名、加密和提供校验和的能力，以确保缓存层能够检测数据篡改或毒害数据的尝试。

CNCF 存储白皮书提供了更多关于云原生存储的概念、术语、使用模式和技术类型的背景资料。

访问

身份和访问管理

综合的鉴权和访问管理（IAM）解决方案在云原生的架构下需要最小粒度的鉴权服务。运维、运营或混合云中的用户和设备均需要进行鉴权。针对基于多云环境的分布式应用和工作，联合鉴权是成功落地的关键。

应用和工作在通信时应该进行明确的授权使用鉴权模块。由于云计算的瞬时性，密钥应被频繁的更换且有效时间应缩短，以保证高速能力和访问控制的需求，并且收敛密钥泄露的影响。

云厂商提供的鉴权服务的使用取决于特定行业的应用场景。独立于云厂商的用户对于凭证和密钥的生成和管理应是机器敏感的，比如医疗和金融信息。

为了让客户端和服务器通过加密技术双向验证身份，所有的工作负载的通信都必须进行相互/双向认证。

在内部环境和跨环境的场景中，鉴权和授权必须是独立决定（决策点）和可执行的（执行点）。在理想情况下，所有工作环境中的安全操作应实时被确认，并且尽可能通过更新后的访问控制和文件权限进行验证，因为缓存可能导致未授权访问（如果访问被撤销并且无法验证）。所有工作负载的授权应该基于它被赋予的属性和角色/权限。强烈建议您的组织同时使用基于属性的访问控制（ABAC）和基于角色的访问控制（RBAC），以便在所有环境中和整个工作负载生命周期中提供精细的授权管理。这样的方案可以实现深度防御，所有的工作负载都能够接受、消费和转发终端用户的身份进行根据情景或动态授权。这可以通过使用身份文件和令牌来实现。如果不执行这一点，就会使组织在系统级和服务级的调用中真正实施最小权限的访问控制能力减弱。

需要注意的是，应用或服务在微服务的背景下身份认证同样也是至关重要的，恶意的服务会欺骗和冒充应用的身份。利用一个强大的身份框架和服务网格可以帮助克服这些问题。

所有的人类和非人类集群以及运维人员都必须要经过认证，他们的所有操作都必须根据访问控制策略进行评估，这些策略将评估每个请求的背景、目的和输出。为了简化认证流程，可以配置联合鉴权，以允许使用公司内的资源，比如多因素认证。然后，必须通过本节提到的访问控制机制进行授权。

凭据管理

硬件安全模块 (HSM)

只要有可能，读者应使用 HSM 技术用加密密钥保护密码学机密算法或信息。如果无法做到这一点，则应使用基于软件的凭据管理器。

凭据管理周期

密码学密钥应在 HSM 或基于软件的密码管理系统中安全地生成。

密钥的有效期和生命周期应尽可能的短，过期密钥应不再有效。密钥管理应该是高可用且易生成的，上述特性是短期密钥的前提条件。虽然不建议使用长期密钥，但如果使用的话，则应建立相应的流程和指导，定期轮换或撤销，特别是在密钥意外泄露的情况下。所有密钥都必须通过安全的通信在传输过程中分发，并应根据其保护的访问权限和数据等级加以保护。

在任何情况下，密钥都应该在运行时通过非持久性机制在工作负载中注入，这些机制不会通过日志、审计或系统转储（即内存中的共享卷而不是环境变量）泄露。

可用性

拒绝服务 (DoS) 和分布式拒绝服务 (DDoS)

在云原生应用的环境中，拒绝服务攻击（DoS 攻击）是一类网络攻击。攻击者试图使云原生应用程序无法为其目标用户（人类或自动化流程）短期或无期限提供服务。攻击者可能通过破坏关键的云原生应用组件（比如微服务）、破坏负责保持微服务运行的协调层或破坏负责扩展应用的健康监控系统来实现这一目的。拒绝服务通常是通过向关键的微服务或资源发送超负荷的请求来实现的，以使系统超载，并阻止部分或全部合法请求。

分布式拒绝服务攻击 (DDoS 攻击）通常涉及大量传入的流量淹没云原生应用服务或它们所依赖的上游网络。通常情况下，攻击是由许多不同的来源发起的。通过在攻击流量到达云原生应用之前进行检测和分流来缓解。

安全保障

从根本上讲，安全性是一个风险管理过程，旨在识别和解决系统带来的风险。并根据组件或组织的风险概况和容忍度，反复不断地强化系统，从而减轻、降低或转移风险。强化的先驱性概念虽然为核心，但仍可以通过评估组件及其组成（以最小但灵活的功能）为基础，将其应用于安全转发团队。例如，当团队发现基础镜像有更新时，应该检查是否需要开通额外端口、更改权限等，并通过阅读更新程序包的注意事项，选择是否需要升级、更改或限制。

与之相对应的，合规标准形成了控制原则，以确定或创建需求定义，并根据这些定义对系统进行评估。评估结果是二元的（通过或失败），但可能包含第 1 类（假阳性）或第 2 类（假阴性）错误，应作为 CI/CD 流水线的测试结果进行评估，类似于流水线中任意测试结果。因此，合规性和安全保证是相辅相成的过程，但不能互相替代。合规系统不能保证安全，安全系统也不能保证合规。

威胁建模

对于采用云原生技术的企业来说，可以选择对应用、数据流、支持流程和基础设施进行威胁建模，从而识别风险，并对风险进行缓解和控制。这个方法类似于典型威胁建模。以下指南是一些用于云原生功能的 OWASP 威胁建模四步法的改进建议。

端到端架构

想要对组织或个人的云原生架构有更清晰的理解，我们应该对数据影响进行指导和分类，这样做有助于团队组织架构内的数据分发，也有助于以后的额外保护机制。云原生图和文档不仅仅包括整体系统设计的核心组件，还应该考虑到源代码存放的位置、使用的存储桶（或其他存储方式），以及软件开发周期的任何其他方面。这些都是在启动云原生的威胁建模时必须考虑的部分。

威胁识别

在考虑云原生能力所带来的针对组织的威胁时，建议利用成熟的、良好的威胁模型，如 STRIDE 或 OCTAVE。基于云原生架构，组织可能需要考虑的常见威胁包括但不限于：

通过社会工程攻击窃取认证凭证，欺骗集群管理员。
篡改 API 服务器配置文件或证书，导致 API 服务器重启失败或 TLS 认证失败。
因为禁用或错误配置 API 审计，否认攻击行为，可能导致缺乏潜在攻击的证据。
如果攻击者破坏了正在运行的工作负载，将数据泄露给外部实体，有可能发生信息泄露。
DoS 攻击导致 pod 没有应用资源限制，从而消耗了整个节点级别的 CPU 和内存，worker 节点发生丢失。
如果 pod 使用不受限制，或采用了较高权限的安全策略运行 pod，又或者修改了 pod/容器的安全上下文，会发生权限变高的情况。

云原生安全需要考虑的威胁行为实体与现有的威胁模型一致。

内部恶意者
内部不知情者
外部恶意者
外部不知情者

建议各组织利用云原生环境中的现有资源，获取有关云原生架构威胁的其他信息。

利用基础设施即代码（IaC）可以为某些威胁提供补偿或减轻控制，也可以减少其发生的可能性。

与任何云原生流程一样，迭代和反馈非常重要。在威胁建模的背景下，这意味着在架构不断变化的情况下，需要重新评估现有的措施、机制和矩阵是否准确地反映其运行状态。

威胁情报

从设计和目的来看，云原生应用是由多个动态组件组成的集合，会受到来自第一方和第三方代码或工具的损害，这就意味着必须对网络活动和云原生应用组件应用威胁情报。网络威胁情报就是关于威胁事件和威胁行为者的信息统称，它可以帮助我们缓解有害事件。云原生系统中的威胁情报将利用在网络或主机上观察到的指标，如 IP 地址、域名、URL 和文件哈希，这些指标将协助我们识别威胁以及行为指标，如威胁行为者的策略、使用的技术以及威胁程序，也可用于识别云原生组件中的威胁行为者活动。MITRE ATT & CK 云框架包括云原生策略和技术，可作为建立和验证可观察性的起点。

事件响应

对于已有事件响应和分流策略的组织来说，应特别注意如何将其应用于云原生工作负载，因为云原生工作负载可能并不总是符合节点隔离（新的 pod 实例可能在不同的服务器上运行）、网络（如 IP 地址是动态分配的）和不可更改性（如对运行的容器进行更改重启后不会保留）等一些基本假设。因此，重要的是要重新审视这些假设，并根据需要重新应用或更新事件响应手册。可观察性和取证工具需要了解云原生的特定构造（如 pods 和容器），以便于维护以及重建受感染系统的状态。在基于意图的编排器中，凭证处理不当有时可能是无意的，因为构建编排器是为了将工作负载视为"牛而不是宠物"去对待。附带说明，从零开始构建事件响应和分流策略虽然是理论可行的，但不在本文的讨论范围之内。

安全栈

环境

运行（工作负载）前安全工具

工作负载前的安全工具应最大程度地加强安全性，并确保遵守最佳安全实践，同时最大限度地减少对托管环境、网络和编排层相关的依赖。工具还应该确保合规性，不会在运行时被破坏。

计算和节点检查

在资源被标记为可以接受工作负载之前，各组织应利用工具来确保计算的加固和安全。因此，建议使用主机漏洞扫描器和 CIS 基准扫描程序。

运行上下文

那些能够进行安全健康检查，并能覆盖工作负载前的表层区域的安全工具最适合作为持续集成工作流的一部分运行，他们可以用来以扫描文件、容器镜像等工件以及基础设施即代码服务。在持续部署工作流中运行的安全工具更适合在特定环境中运行，并根据具体环境进行具体配置。支持准入时间检查概念的云原生编排器，允许组织利用准入交付挂钩，可以对工作流早期阶段的工具进行应用以及补充。

运行时安全工具

工作负载和主机运行时安全

运行时安全工具可以分为四个主要保护区域。

进程、容器或系统级安全
网络安全
数据安全
应用安全

对于任意一个适用于组织关注领域的保护区，应使用多种工具相组合。策略驱动型工具可实施基于规则的策略，无论是手动编写还是通过推荐系统编写。一旦投入应用，这些策略驱动的工具将提供可预测的结果，并可在监测模式或执行模式下应用。

威胁和漏洞反馈使安全工具能够拦截来自未知或已知威胁的异常行为和安全事件。这些信息源通常会定期、频繁进行更新。使用这些反馈能够提供一个防御层，驱动工具以补充策略，并且可以实施到覆盖大多数保护区域的工具中。团队应在反馈中寻找已知的 C&C（指令与控制）服务器、加密域、恶意软件文件校验等网络威胁情报，从而协助更新策略工具。

现有的工具可以提供机制来管理假阳性和假阴性问题产生的噪声，处理已知的威胁，并使用策略驱动的防护栏来规范操作。但是基于机器学习（ML）的安全工具给我们提供了一个对已知和未知威胁的检测层，能够超出可预测工具建立的预测边界。例如，基于行为分析身份授权日志，以检测内部人员威胁和违规行为，或自适应分析协调器审计日志，以检测漏洞尝试或服务账户盗窃。对主机系统调用模式进行机器学习驱动分析，可用于检测容器逃逸或主机利用企图。

监控和跟踪各种云原生编排安全的编排安全工具通常作为特定领域的商业产品提供，其功能范围应用广泛，包括细粒度的策略控制、合规性检查、基于人工智能/机器学习的异常检测和良好集成。

与任何云原生工作负载一样，用于监控、报告或控制环境安全的工具也应该是云原生的，以便于使用、管理和部署。

零信任架构

零信任架构能够通过细粒度分割、微边界，以及通过验证和执行策略消除对数据、资产、应用和服务（DAAS）的隐性信任，从而减轻了网络内横向移动的威胁。零信任架构最常见的实现是依赖密码学概念进行零信任。这主要是认为能够将特定的关键材料安全地保存在硬件或令牌中，并能够以一种平台间安全传递的方式进行管理。

零信任架构的基础构件，通常包括几个方面。

每一个实体都可以创建证明身份的凭证。
实体能够独立认证其他身份（即公钥基础设施）。
各实体之间的通信保持保密，并互不干扰。

零信任框架通过利用权威的信任根来创建零信任构件，其基础构件是将防篡改信任与实体或流程绑定的能力。然后，它需要拥有证明、验证实体身份的能力。以容器服务为例，我如何检查这个容器是否符合其声明的身份，这需要和编排器进行验证，但要想信任编排器，我们需要确保它的运行不被篡改，这只有在我们运行在受信任的操作系统、BIOS 时才能得到确认。认证其实也是一条链。

零信任还需要实体之间的安全通信。虽然网络分段为零信任架构提供了价值，应该予以考虑，但这并不是实施零信任的全部解决方案。编排网络策略以及服务网格的使用都是综合零信任解决方案的组成部分。更多关于零信任概念的信息可在网上广泛获取。

权限最小化

最小权限也很重要，或者可能是云原生架构中最重要的部分，必须在做出认证或授权决定的技术栈的所有部分进行考虑。传统实践中，最小权限是在控制在账户层面的，无论这个账户是人还是服务。

在云原生环境中，必须在堆栈的每一层应用最小权限。在评估负责履行每层执行的具体工具时，也应考虑到这一点。在探索各种产品和功能中，组织可能会发现，许多容器需要默认的权限部署或需要 root 权限才能操作。因此，可能需要采取额外的措施，将这些较高的权限与工作负载的其他部分隔离。各组织应考虑在其工作负载和部署中采用隔离和最低权限的所有领域；从运行时环境中的 cgroups 和系统调用，过度到构件管理和非 root 权限构建。

为了持续减少潜在的攻击面和相应的影响范围，组织需要在其架构的每一个层次上实施最低权限原则。这不仅适用于在其角色中执行各种功能的个人，也适用于在特定环境中执行的服务和工作负载。如果攻击者进入组织的环境，非 root 服务和容器对于确保安全至关重要，能够确保攻击者不能轻易地在他们获得访问权的容器与底层主机或其他主机上的容器之间进行穿越。

强制性访问控制 (MAC) 的实现（如 SELinux 和 AppArmor）可以限制权限，无法超出为容器或命名空间设置的权限，并能在主机级别提供额外的容器隔离，以防止容器越狱或从一个容器转向另一个容器的过程中得到超出现有访问控制允许的权限。

角色和责任

在迁移到云原生架构和部署时，组织应该注意到传统安全角色和责任的调整，创建云原生特有的新的安全角色。随着现代开发方法论的快速发展，以及 IT 活动与业务需求的更好结合，安全必须具有适应性、与实际风险相称的应用和透明性。期望开发人员和运营人员成为安全专家是不合理的。安全从业人员需要与开发人员、运营和其他项目周期要素合作，使安全性和合规性执行与流程现代化工作和开发生命周期充分结合。这样做意味着开发人员将使用其惯常的工具实时报告发现的问题，以便快速解决，类似于项目构建失败之后，通知开发解决的流程。

在云原生环境中管理安全问题时，DevOps 环境中经常出现的模糊界限不应该替代明确的职责分离（SoD）。尽管开发人员将更多地参与到安全措施的实施和执行中，但他们无需设置策略，不需要了解他们不需要的领域等等。这种分离应该根据组织的风险承受能力和业务实践，在角色之间以及在跨产品和应用团队之间实施。可以预见的是，为了保持业务的繁荣，个人需要履行更多的职责，这意味着在小型组织中将会变得十分困难。然而，随着组织的不断发展，在认知上将迫使个人执行的活动进行心理转换，在权限的调整中发挥独特的作用，可以帮助执行 SoD。最终，允许将重组角色重新分配给新的个人，而不会随着新的任务增加访问范围。

随着产品和服务向云计算迁移，组织将需要重新评估其资产风险。随着使用中的技术及其部署堆栈的所有权和管理权的变化，管理人员应期待重大的风险状况变化。提供商和团队之间的共同责任将要求改变风险接受阈值，使用新机制进行转移和缓解。

合规

依照监管和合规的指导设计一个具有适当安全控制措施的系统，保障了云原生资源的安全性。这样做使得通过相关监管机构和审计人员的认证变得更加容易，如果在系统设计和规划中采用了插件模式来实现对各类监管的自动合规，那就更好了。尽管合规通常要求使用安全基准来提高安全性和配置管理的执行，如互联网安全中心（CIS）基准，但需要注意的是，建议使用机器可读的合规性控制框架和语言。

监管审计

许多金融、卫生、政府和其他实体需要遵守一套特定的系统保护要求。用户信任系统能保证他们的交互的私密性和安全性。每个组织都应该评估哪些监管标准适用于他们（例如 PCI-DSS、HIPAA、FedRAMP、GDPR 等）。然后，他们应决定监管标准如何适用于他们的云原生系统，以及他们将如何在根据实际情况实施这些标准。这种支持遵守特定标准的证据收集机制应尽可能通过不可抵赖性保证自动化。

角色和用例

重点是安全、保护、检测和尽可能的自动响应。它不一定是独立的开发工具，而是透明地集成到开发流程中的安全工具，使得开发过程中就能够执行安全策略、快速反馈和直接补救。有关云原生安全用例的具体信息，请参考 TAG-Security 的用例列表。

行业

企业

企业成功采用云原生模式的核心关注点是，在满足业务目标的同时，保持当前的流程和程序。当整个组织引入新的标准和实践时，保持互通性，将数据丢失、泄漏或其它安全风险控制在最低限度。

小微企业

小微企业成功采用云原生模式的核心关注点是，能否专注于短期目标，能否促进创新以应对激烈的竞争。资源、预算、技术深度和缺乏最佳实践阻碍了他们采用云原生解决方案的能力。小微企业需要可复制的模式和小步快跑的 IT 计划来解决这些挑战。

金融

金融行业成功采用云原生技术的核心关注点是，未经授权的信息泄露，欺诈和资金可用性。欺诈会直接影响到资金的可用性，而金融交易的完整性至关重要。

医疗保健

医疗保健行业成功采用云原生技术的核心关注点是，未经授权的信息泄露，记录的及时性、可用性以及准确性。根据医疗行业的性质和实践经验，记录及其相关内容的可用性是做出医疗决策的基础。在缺少这些信息的情况下，就需要发掘新的记录。

学术界和教育界

教育机构成功采用云原生技术的核心关注点是，可能的终端用户的需求。面向未成年人的机构有额外的法律要求以保护隐私，因此访问控制就非常重要。除此以外，各机构还会关注教育内容对终端用户的可用性。

公共部门

公共部门成功采用云原生技术的核心关注点是，安全、数据主权、合规性和供应商锁定。它们的阻碍来自于机构为保护公共利益而制定的法规。对公共部门而言，维持公众和政府之间的和谐、信任是重中之重。此外，部署和功能的及时性也是一个重要的考虑因素。采用云原生，加上现代方法论，可以提高组织效率，这对公共部门的许多领域都非常重要。

云原生安全的演变

容器技术不断发展，并得到了广泛的应用。于此同时，云原生技术的威胁场景在不断增加，应对和解决这些威胁的安全挑战也在不断变化。再考虑到安全容器平台所处的复杂生态系统，这些都需要一个整体规划的、深思熟虑的安全策略，并对安全策略的执行、响应和操作制度进行技术控制及自动化。

如果实施得当，容器化可以为安全带来巨大的收益。它能提供更大的透明度、模块化，减少了攻击面，使得应用升级更方便，并保证了应用运行环境的一致性。这种一致性使得安全策略能够在开发、测试和生产环境中并行实施。如果实施了分层深度防御安全策略，并在应用间建立了适当的隔离（采用扁平网络的企业中基本上都会实施微分组），当发生企业范围安全事件时还可以减轻其影响。

鉴于当下面临的各种安全问题，安全工具的需求巨大，而市场上技能和人才却又短缺，如何确保容器平台的安全将是一个巨大的挑战。我们预计，随着云服务商提供的容器产品越来越成熟，也会有越来越多的云原生的安全和智能的工具集成进来，帮助整合种种兼容规格，促进更多的服务迁移到云端。这些产品将会是共享责任模型的一部分，从而减少了企业的开销。

采用容器技术，进而采用云原生技术，将持续推动企业的数字化转型。企业已经在利用无服务器架构和设计来提供部分服务，但将全部服务改造至无服务器架构仍然任重道远。将一套业务功能分拆成大量的函数编排会丧失部分的可视性，以及已经存在的或正在涌现的各种尚未知晓的安全挑战，这些都会成为阻碍。简而言之，只有服务提供商的安全控制能做到和如今的容器生态一样帮助消费者减少开销，无服务器技术在云原生架构中的采用中才能日益增加。

威胁发生的场景总体而言保持不变，攻击者始终在不断发觉和利用顶级漏洞。我们能观察到的最显著的变化是攻击手段和机制开始针对云原生组织和应用。针对容器编排和部署的攻击都在增加，这一点从通过渗透或木马镜像进行的密码挖掘攻击的增加就可以看出。如同其它创新技术从新兴到繁荣的发展历程一样，恶意攻击者对唾手可得的利益产生兴趣只是时间问题。

随着这些攻击变得更普遍、更扩大、更错综复杂，云原生安全技术必须不断发展，也需要让企业和 DevOps 团队提升目前的重视程度。我们看到安全策略即代码的使用越来越多，但在安全策略的执行、检测和响应方面，还有很大的演进和自动化的空间。很明显，即时、自动化的智能安全响应将是挫败攻击乃至自我修复的关键。甚至可能在攻击发生时自行调整和整合 [^10]。

容器取证工具和技术也需要不断发展，以跟上云原生的步伐。这一点尤为重要，因为在 IaaS 和其它 -aaS 的场景下，事故的数量和复杂性都在增加。

结论

在过去的 15 年里，社区见证了云服务和技术的快速应用，最近更是大力推动云原生模式的发展。与安全行业的任何新商品一样，创新者们都在摸索和推动技术的早期应用和尝试。

对于决心做技术更新换代的组织，或早期用户来说，认真分析和实施核心安全理念是至关重要的，因为这样才能缓解加固和环境控制带来的滞后性。

虽然对于我们今天看到的和未来即将到来的大多数创新来说，可能还不存在针对性的安全指导和控制，但在设计、开发和部署新功能时，应当时刻遵守云原生架构中的核心安全概念。

这些核心安全概念是：

防范未经授权的访问（包括人的操作和非人实体的操作） - 资源的生命周期应当尽量短暂，只能实时从已知的授权状态上派生出来，这样会降低被暴露给未经授权实体的机率；
不可更改，以保持内容和代码的完整性；
服务、工具和内容的可用性 - 通过分布式架构提供弹性和冗余；
审计和问责 - 提供一种机制，以确保不会发生违规操作，并能跟踪经授权的变更。

缩略语和词汇表

ABAC - 基于属性的访问控制

IAM - 身份和访问管理

RBAC - 基于角色的访问控制

SOC - 安全运营中心

IaC - 基础设施即代码

DevOps 研发运维（一体化人员）

DevSecOps 研发安全运维（一体化人员）

pipeline 流水线

CI - 持续集成

CD - 持续部署

HSM - 硬件安全模块

参考文献

NIST 800-204 基于微服务的应用系统的安全策略

NIST 800-190 应用容器安全指南

https://www.cisecurity.org/benchmark/Kubernetes/

威胁建模。12 种可用方法

https://owasp.org/www-community/Application_Threat_Modeling

NIST 应用安全容器指南、互联网安全中心 (CIS)、NIST 微服务安全策略和 OpenSCAP 基准存在于 Docker、Kubernetes 和几个托管 Kubernetes 发行版。

Kubernetes 的 MITRE ATT&CK 矩阵

鸣谢

本白皮书是由 CNCF Security-TAG 成员推动的社区工作。感谢大家的杰出贡献。特别感谢 Emily Fox 和 Jeyappragash JJ。

原版撰稿人：

Aradhna Chetal - TIAA
Brandon Lum - IBM
Chase Pettet - Mirantis (Chase.Pettet@mirantis.com)
Emily Fox -- US National Security Agency (NSA)
Gadi Naor - Alcide
Harmeet Singh - IBM
Jeff Lombardo
Jeyappragash JJ↓↓↓↓Tetrate IO
Pushkar Joglekar - Visa
Rowan Baker - ControlPlane
Andrew Martin - ControlPlane
Trishank Karthik Kuppusamy--Datadog。
Vinay Venkataraghavan - Prisma Cloud (Palo Alto Networks)
Wayne Haber - GitLab
Mark Bower
Alex Chircop - StorageOS

原版审查者：

● @justincappos

● @lumjjb

● @whaber

● @craigbox

● @anvega

● @magnologan

● Alok Raj - XenonStack (alok@xenonstack.com)

● @nyrahul

● @ranio1

中文译者：

@rootsongjc
@N3erox0
@cafra
@aiaicaow
@hbrls
@losery
@knwng
@babysor
@gtb-togerther
@dwctua

注释

[2]: 例子 - MITRE ATT&CK Kubernetes 框架

[3]: 安全左移往往会让组织疏于运营阶段的安全监控。需要强调的是，安全存在于生命周期的所有阶段，组织应当不断评估其业务和技术流程，注意那些可能会超越现代安全范式的方面，从而将安全视作一种文化和习惯来培养

[6]: 根据 Applied Software Measurement，Capers Jones，1996，并根据通货膨胀进行调整 - 85% 的缺陷是在编码期间引入的，如果此期间能修复则成本为 41 美元，而发布后的修复成本为 26,542 美元。

[7]: cIsecurity.org 维护了一份加固基准清单。

[8]: 值得注意的是，尽管一般都会采用单向认证机制，但首选推荐使用双向认证，即不仅验证客户端，也需要验证服务端（流入与流出）。

[9]: 使用了 VPN 并不等同于加密。

容器云安全中心网络安全安全安全漏洞

0 人点赞

云原生安全白皮书中文版