原文：Cloud Native Security White Paper

执行摘要

目的

云原生的开发和部署模式已经成为业界趋势，技术、产品、标准和解决方案的生态系统也在同步的扩张之中，决策者面临着跟进复杂设计的挑战。CISO 要在这个动荡的战场中实践业务价值，这个角色显得尤为重要。云原生模式鼓励消费模式的变化，和采用需要集成安全实践的现代工作流程（如敏捷方法和 DevOps）。

问题分析

面对快速开发和部署的迫切需要，基于边界的传统安全保障显得力不从心。传统安全方法偏重于对边界进行保护，而更复杂的云原生应用则倾向于识别动态工作负载中的属性和元数据来进行保护，这样才能为应用的模式转换保驾护航。这种方式能对工作负载进行识别和保护，以此适应云原生应用的规模扩展以及快速变化的需要。模式的转变要求使用面向安全的架构设计（例如零信任），并且在应用安全生命周期中采用更多的自动化方法。作为云原生环境的典型特征，容器化也需要最新的最佳实践。安全措施的变更会触及组织内的多个利益方，并且会对开发和运维人员的生产力造成影响，因此其权衡过程会持续存在。云原生应用并没有跳出开发、发布、部署和运维的圈子，但是新的模式需要新的安全机制，从而保障（新方式下）能够保障这些环节目标的达成。云原生应用的生命周期可以建模为开发、发布、部署和运行时这样几个不同的阶段。和传统安全方法相比，云原生安全有机会在不同的阶段注入各自的安全保障，而不是用独立的安全措施来干预应用的生命周期。需要指出的是，需要针对这些概念的使用和整合、相关工具和流程的教育和培训，云原生的落地和应用可能难以为继，甚至被打回原形。

生命周期

开发

对云原生应用来说，建议在应用生命周期的早期就引入安全保障。尽早地使用安全测试来识别合规和配置的相关问题，从而为持续改进提供快速、可操作的反馈流程。这种方式能够使用同样的工作流程来处理安全问题和 Pipeline 中的其它常规问题（例如 Bug 修复或者 CI 失败）。这种模型中使用的现代的安全方法符合设计模式（例如 12 要素）要求，并且能保障交付过程的完整性。云原生的概念和 IaC（基础设施即代码）的实践密不可分，以此确保能够在早期进行安全检查后，按照预期执行。这样的过程能够识别错误配置，并可以尽早在 IaC 和编排清单中实施最佳实践，从而降低长期成本并提高安全价值。

发布

软件供应链安全在快速的软件迭代过程中尤其重要。云原生应用的完整性保障不仅针对工作负载自身，还需保证其创建和运维过程的完整性。对于开源软件和第三方应用的强依赖加剧了这方面的要求。Pipeline 生产的制品（例如容器镜像）需要持续地进行自动扫描和更新，从而避免遭受漏洞、恶意软件、危险代码以及其它不当行为的侵害。完成这些检查之后，应该对制品进行签名来保障其完整性和不可否认性。

部署

在开发和发布过程中集成的安全性能够对候选工作负载的属性进行实时的持续的验证（例如制品签名的验证、容器镜像和运行时的安全策略等）。随安全的工作负载同时部署的可观察性支持，提供了对日志和指标的支持，进一步完善了安全保障的覆盖面积。

运行时

云原生运行环境应提供策略和资源限制功能。对工作负载进行运行时资源限制（例如 Linux 的 cgroup 隔离）就是一个在云原生环境中进行限制和可观察性的原语的例子。可以把云原生运行时环境分解为具备不同安全问题的关联的组件层（例如硬件、主机、容器镜像运行时和编排）。

在云原生环境中，普遍采用了微服务架构。应用通常会由独立且目标单一的微服务组成，这些微服务需要通过服务层进行通信，容器编排层完成了这一任务。这种相互纠缠的组件架构下，安全方面的最佳实践包括只有被许可的进程才能在容器的命名空间内运行、预防和告知未经授权的资源访问、以及能够感知恶意行为的网络监控。服务网格是另一个常见的抽象，它在避免对工作负载进行变更的情况下，为被编排的服务提供了加固和补充的功能（例如 API 流量日志、传输加密、认证、授权以及可观察性等）。

建议

相对传统安全模型，云原生安全同样要对尽职性、完整性、信任关系以及威胁防范提供支持，在此基础之上还加入了临时性、分布式和不可变设施的现代概念。在这种快速变化的环境中，要在迭代中实现与开发 Pipeline 自动同步的安全保障才能防止迭代失败。组织必须对这些核心安全概念进行学习分析和应用，避免在应用加固和环境管理方面的落后；需要对相关的第三方执行同样的标准；并对其云功能和安全支持方面的员工进行持续的教育和培训。因为复杂性的增加和组件的复杂关系，必须通过在整个生命周期和运行环境中整合安全保障能力来制止未授权访问。强烈建议组织根据攻击框架[^2]来确认安全堆栈的覆盖面。另外组织还可以采用安全左移[^3]的方式，扩大 DevOps 的能力，在 Pipeline 执行之前、之中和之后进行持续、适用的检查，对进入生命周期的任何新东西进行校验。

结论

如果一个组织以战略的高度重视云原生安全的落地工作，能够在大规模情况下提供高可用、可信、韧性和冗余的应用能力，保证客户和开发者能够以他们期望的效率，安全地访问所需资源。安全是一个跨学科领域，并不能独立于开发之外，也不仅仅局限在技术范畴。开发、运维和安全人员都必须紧密交流和协作，推动该领域的持续进步。与任何技术创新一样，真正使社区和云原生安全成为可能的是人。

简介

本文尝试让组织及其技术领导者能够清晰地理解云原生，从而能够将其纳入原有生命周期，并确定其应用方式。云原生安全是一个覆盖多个专业技术和实践领域的多目标、多约束的问题空间。在初期运维过程中有很多工作都和安全领域重叠，例如身份管理和存储方案。然而云原生安全的覆盖面远不止于此，它还是一个关系到人本身的问题空间，其中包含了个人、团队以及组织。它是一种机制和流程，人类和系统借此进行交互，对云原生应用和技术造成深远影响。

目标读者

我们的目标读者是希望交付安全云原生技术生态的企业、政府机构以及非营利组织的首席安全观(CSO)、首席信息安全观 (CISO) 或者 首席技术官 (CTO) 。其它的组织利益相关方，包括负责设计实现安全云原生产品和服务的项目经理、产品经理和架构师。当然其他对云原生安全有兴趣的人也都可以参考本文。

云原生的目标

包括容器和微服务架构在内的新技术的采用和创新带来了新的挑战。现代组织中，安全需求的优先级已经大幅提升。围绕云原生技术的加速创新，威胁范围也在扩大。安全领导者要负责保护人力[^4]和非人力的资产，要在满足严格合规性要求的同时，采取措施来预防、检测和对应安全问题。一个老生常谈的埋怨就是，安全措施降低了 DevOps 团队的速度和敏捷性。因此安全领导层必须（和 DevOps 团队）进行更紧密的合作并增进双方的理解，让 DevOps 团队也能同样共享网络风险方面的所有权。

企业需要采用的安全云原生模式和架构必须进行分享，确保业界能够用更高优先级来实施安全实践，并将其集成到现代应用生命周期之中。强调安全架构和安全行业领导者的协同作用，并在漏洞管理、零信任、云安全和 DevSecOps 等方面调整组织的架构目标，这是当务之急。

本文中的概念是具备普遍性的，并不偏向于特定的组件或者服务。

但是这里并不会对安全和云原生方面的基本概念进行扫盲，也不会推荐特定的技术和工具，当然，叙述过程中可能会使用一些相关工具被列举在相关专题中，或者进行示例。

除了本文中的建议之外，与数据和隐私保护（例如 GDPR、PCI DSS）的相关内容需要额外的监管相关的方面进行考虑。建议读者另行寻找相关咨询资源对这方面的技术控制和合规风险提供支持。

假设

CNCF 在 CNCF 技术监督委员会（TOC）的 GitHub 仓库中提供了云原生的定义。本文不会改变这一定义或对其进行扩展。

云原生的落地和现代软件开发方法论都在持续演进之中。构成云原生技术栈的技术也会随着时间的推移不断变化。云原生 Landscape 中会持续支持这个不断变化的技术栈。

本文中出现的工作负载这个词，代表已经或者将要开发、运维、发布以及部署到基于云的运行时环境的任何产品、项目、应用或者系统。

云原生的层次

图 1

云原生技术栈由基础、环境和生命周期构成。云原生技术栈可能用不同的模型（例如 IaaS、PaaS、CaaS 或者 FaaS）进行部署。每一种模型都提供了各自的抽象，以此来简化云原生环境的管理和运维。这些模型中有一些是已经广为人知并被广泛采用，我们会聚焦在云原生特有的模型上。

CaaS（容器即服务）模型让用户通过基于容器的虚拟化平台及其 API 或者 Web 管理界面对容器、应用和集群进行编排和其它管理工作。CaaS 帮助用户构建容器化应用，其中内置以代码方式表达的安全策略，这些应用能运行在私有云、自建数据中心和公有云上。CaaS 有助于简化容器的构建过程。有了微服务的编排和部署，CaaS 帮助企业更快地发布软件，并且具备在混合云、多云环境下的移植性，同时还降低了基础设施和运维成本。CaaS 模型之所以能节约成本，是因为它能够帮助企业简化容器管理，并给企业仅为实际的 CaaS 需求买单的选择。CaaS 以容器为基础资源，而 IaaS 环境中的基础资源则是虚拟机和裸金属。

FaaS（功能即服务）是另一种云原生部署模型，它是一种云原生服务的形态，让企业用户能够根据事件来触发代码的执行，避免了构建运行微服务的复杂的基础设施管理工作。在云上运行应用通常提供虚拟环境，管理操作系统和 Web 组件等。有了 FaaS 之后，物理硬件、寻积极操作系统以及 Web 服务器软件管理都由云服务提供商自动支持。这样一来，用户就能专注于单独的微服务功能代码，并且只需要向云服务商用弹性的方式支付资源的实际使用费用。

生命周期

云原生语境下的生命周期指的是在云环境下，帮助实现有韧性、可管理、可观测的工作负载的技术和实践。如图一所示，生命周期由四个持续阶段构成：开发、发布、部署和运行时。每个阶段都是前一个阶段的扩展和放大，同实要放行安全工作负载的运行，并提供相应支持。

生命周期过程

对于安全实现来说，供应链的管理和合适的安全基线是非常重要的。

供应链

组织有责任确保它们开发的工作负载的供应链能够接受可操作的安全分析。供应链安全可以分为两个部分：为创建工作负载供应支撑环境的服务和工具（开发工具）的安全，以及组成工作负载的组件（例如库、依赖和镜像）的安全。供应链必须以能够接受检查的方式来构建，软件供应链输出的制品也应该能够使用签署的方式确认来源。为保障依赖项的正常运行并阻止可能的破坏行为，对第三方包的真实性和完整性进行校验非常必要。

云原生应用的一个显著特征就是软件复用，这些软件可能以软件包或容器镜像的方式，通过开源仓库进行构建和分发。正因如此，对于开发、运维和安全人员来说，确保应用中的制品和依赖不包含已知的恶意软件和缺陷是个必要工作。容器镜像可能包含的恶意软件，很明显会威胁到运行时环境[^5]。在持续集成过程中和容器仓库中进行周期性扫描和按需扫描能够有效防范这些问题。

使用这些手段实现可检测的、安全的软件发布和运维操作。在工作负载的产生过程中进行威胁检测让组织能够快速向开发团队进行反馈，并阻止不安全的或有漏洞的更新被发布和部署。对现存软件进行周期性的扫描，能够发现新公布的问题，从而避免其造成危害。

安全基准

安全基准（例如 NIST Application Security Container Guide、 Center for Internet Security (CIS), NIST Security Strategies for microservices 以及 OpenSCAP）为开发团队和组织提供了创建“缺省即安全”的工作负载的指引。采纳并实现这些安全标准，让团队能够基于加固的基线进行测试。然而这些基准无法深入数据流，也无法干涉平台的用法。因此这些内容应该作为一个指南，而非检查表。

接下来的几节将详细分析在整个应用程序生命周期中集成安全的意义、工具、机制和最佳实践。

开发

图 2

云原生应用的安全需要体现在应用的整个生命周期之中。开发环境是这个周期的第一个环节，这个环节输出的是制品，例如 IaaS、应用和容器清单等，这些制品会被用于云原生应用的部署和配置。经验表明，这些制品会是多种攻击的来源。接下来的内容会介绍这个阶段里需要介绍多种工具、流程和检查过程，以此减少运行时应用程序的攻击面。

开发过程中的安全检查

在应用开发过程中的安全加固是一个重要环节。安全需求也是需求的一部分，应该尽早在软件开发过程中进行引入。安全需求通常是围绕业务的风险和合规性进行的。这些需求如果不在早期进行处理，而是在生命周期的后续才开始进行的话，就会拖慢 DevOps 过程，提高总体成本。DevOps 团队还需要使用专门工具在这些应用的部署之前对危险配置和漏洞进行检测。这些工具应该无缝集成到 DevOps 团队现有的熟悉的工作链之中，在不阻碍敏捷性的同时，提高安全性。例如可以在开发 IDE 中或者创建 PR 的时候对 IaaS 模板以及应用清单文件进行扫描，并生成丰富的上下文相关的安全信息，开发团队就能够尽早、迅速、轻松地采取行动。加入这些步骤后能够避免已知漏洞和高危配置。云原生组件应该是 API 驱动的，被编排的业务应用能够和复杂的调试工具进行交付。

团队应该部署独立的开发、测试和生产环境，从而为应用开发者提供隔离的设施，对基础镜像、容器、应用、虚拟机镜像以及进行开发、测试和部署。有些组织可能已经在尝试金丝雀部署和蓝绿部署。以及其他部署模型在现场进行动态和交互测试，以此进一步提高效率。

测试方案的开发

开发、运维和安全人员应该为关键业务、有高威特征、变化频繁或具有历史问题的代码和基础设施建立测试方案。威胁建模可以识别高风险和高影响的代码热点，提高开发测试的投资回报率（ROI）。测试对象可以包括部署、操作系统、基础设施和数据库加固、应用测试（静态和动态源码测试、容器配置）、集成或系统测试（应用程序和基础设施组件及其交互的验收）和冒烟测试（针对实时系统的部署后检查）。测试作者应该能够全面地访问开发和测试环境，从而能够快速地开发测试方案，同时减少持续集成（CI）反馈循环次数。作者应该能在本地和共享测试环境中运行系统测试套件。

代码评审

对工作负载或基础设施的细微变更可能引发意料之外的安全问题。为减少风险，建议合并 PR 之前应用四眼原则进行评审。

发布

图 3

这个阶段会使用镜像定义和规范来构建后续步骤的制品，例如容器镜像、虚拟机镜像等。在现代 CI/CD 语境下，发布阶段中包含了系统性的应用测试，以此识别软件中的 Bug 和故障。然而对开源软件和包的复用，有可能会把安全威胁引入到制品之中。为了防止这种情况，需要对制品进行扫描，并验证其完整性，防止发生篡改。后续内容会为开发和运维人员介绍识别和保护容器镜像、CI/CD 流水线的工具、技术以及基础设施。还可以对制品进行加密来满足额外的保密需求。

如果遭遇泄密等问题导致制品不可信，应对密钥进行更换并重新签署。

构建流水线

不同安全级别和敏感性的项目，应对 CI 服务器应进行分别的隔离和保护。需要提权的基础设施构建应在专用的持续构建服务上运行。编排器应该为流水线创建和执行构建策略。

供应链工具可以对流水线的元数据进行搜集和签名。后续步骤能够对签名进行检查，并借此确信前面的步骤已经完成。

读者要确保 CI/CD 设施的安全。例如及时进行安全更新，并通过硬件安全模块或者凭据管理器对密钥进行保护，防止泄露。

镜像扫描

镜像扫描是应用镜像生命周期中的重要步骤。在把镜像部署到生产环境之前对其进行扫描是非常必要的。具备了这一能力之后，开发、运维和安全人员就能够获知已知问题的详细信息例如严重性、CVSS 评级以及对应的补救和修复措施。将容器漏洞扫描和流水线的合规规则结合在一起，能够确保仅有打过合适补丁的应用能够部署到生产环境，从而降低攻击风险。容器扫描还能帮助识别开源软件包和基础镜像中可能存在的恶意软件。镜像扫描仅是对现状的识别而非预防措施。组织需要谨慎选择扫描工具、在合理的环节中进行调用，在合乎规则的情况下，提供可操作的输出信息。

镜像加固

容器镜像是构建管道的第一次输出。因此必须对其进行安全加固，加固过程不仅需要考虑降低威胁，还要为整体环境下的应用运行提供可配置的能力。

需要在安全保障目标中评估以下几个问题：

• 执行环境应该限制到特定用户么？
• 资源访问应该受限么？
• 需要在内核级对进程执行做限制么？

容易应用清单扫描

应用清单描述了部署容器化应用所需的配置。正如在安全基准部分介绍的那样，NIST 800-190 之类的材料中推荐了容器化应用的最佳安全实践和配置。可以在 CI/CD 中对清单进行必要的扫描。

容器化应用清单的加固

和容器镜像类似，容器应用清单的加密也可以在构建和运行时进行。

需要在安全保障目标中评估以下几个问题：

• 满足环境运行目标的最小化限制是什么样的？

测试

云原生应用应该适用于传统应用相同的测试套件和质量标准——例如代码清洁、[测试金字塔]()[(https://martinfowler.com/articles/practical-test-pyramid.html]，为开发人员提供测试所需完整的基础设施，通过静态安全扫描（SAST）、依赖分析和扫描、动态应用安全测试（DAST）（例如 Mocking）等，为安全和合规提供实时的保障能力。

确定了安全问题之后（例如错误的防火墙或路由规则），进行根本原因分析之后，如果认为它有可能重复发生的话，开发人员就应该编写一个自动化测试，防止问题卷土重来。在测试失败时，团队应该收到反馈，改正 bug，试图在下一次合并中通过测试。（有效的测试）能够防范对同一段代码的变更造成的问题复现。

基础设施的单元测试是预防性措施，测试目标是基础设施即代码（IaC）配置中涉及的实体和输入项。针对现存基础设施的安全测试是一种检测性控制，并包含了保障、历史回归和意外配置检测（例如防火墙规则全面开放、过度授权的身份与访问管理（IAM）策略、未认证的端点）等内容。

基础设施和工作负载的加固应得到全面测试套件的支持，随着系统的成熟，基础设施和工作负载也能得到逐步加固。在构建过程中应该有对加固项目的测试，这些检查也应该在部署时执行，以评估整个生命周期中可能发生的变化或回归。

静态分析和安全测试

IaC 和应用清单、软件代码以及 IaC 的静态分析过程可能包括对错误配置的识别和漏洞扫描。IaC 代码应该和应用工作负载使用同样的流水线策略控制。

IaC 日益流行，越来越多组织使用这种方式来进行云和容器基础设施的部署，所以要警惕其配置问题可能暴露的攻击面。

在进行应用和基础设施的部署之前，应该对这些模板进行扫描，发现其中的不安全配置和其它安全问题。需要着重考虑的几个方面：

• 应用清单中包含的漏洞镜像。
• 一些不当配置（例如允许特权逃逸）。
• 安全上下文和系统调用可能对系统产生威胁。
• 资源限制。

动态分析

对已部署的基础设施进行动态分析，可能包含 RBAC 和 IAM 配置的检查，对网络暴露面的校验。确认 SOC 能够在各个环境中生效。动态分析也应该是测试的一环，应该在非生产环境中运行。

安全测试

对应用程序进行自动的安全测试是安全团队的工作焦点之一。测试套件需要进行持续更新，和组织入侵模型一致，能够对系统进行持续的可复用的安全测试。自动化的安全测试避免了人工的检查点控制，降低了时间消耗，提高了安全性和发布效率；自动化安全测试还能够显式的执行安全威胁来按需展示控制能力，从而提高系统安全性，并保持合规性。

制品和镜像

仓库

开源组件经常是从公共源中拉取的，组织应在管线中为各个阶段创建仓库。只有认证的开发者能够访问共有仓库，拉取基础镜像，基础镜像被保存到内部仓库，被组织中的团队大量使用。不同的团队或小组应该使用独立的私有仓库来保存各自的开发中的制品，最后一个 Staging 或预生产仓库用于保存用在生产环境里的镜像。 这中措施能更严格地控制开源组件的出处和安全性，同时可以对 CI/CD 链的各个阶段进行不同类型的测试。

不管是什么仓库，都必须通过专门的认证和权限模型实施访问控制。对所有的连接都应使用双向 TLS。

签名、信任和完整性

在构建时对镜像内容进行签名，在使用前对签名进行校验，能够保证镜像数据在构建和部署之间不会被篡改，这样就保证了制品的完整性和可信性。确认过程首先要表明一个制品是经过审批的，还要验证制品是否具有有效的签名。在最简单的情况下，每个制品都可以由一个签名者签名，表明制品通过了测试和验证过程。然而多数情况下的软件供应链是比较复杂的，一个制品的构建依赖于多个验证步骤，因此需要有一组实体的认证。这方面的例子有：

• 容器镜像签名：对容器镜像清单进行签名的过程。
• 配置签名：对配置文件进行签名：GitOps 方式中很常见，能够对配置进行检查和验证。
• 包签名：对一个制品包进行签名。

对于通用软件工件，如库或 OCI 制品，签名表示它们的来源是经组织批准使用的。制品的签名和验证非常重要。强烈建议仓库使用双向认证，对仓库中镜像的变更或者提交代码都需要进行认证。

加密

对容器镜像进行加密，可以保证其数据的机密性，从构建阶段到运行阶段，数据都是保密的。即使发布过程受损，镜像内容仍然是保密的。这种机制可以用于保护交易密文或者其它机密材料。

镜像加密的还有一个使用场景就是对容器镜像进行授权。当镜像加密与密钥管理和/或授权和凭证分发相结合时，可以要求容器映像只能在特定平台上运行。容器镜像授权对于合规性使用案例非常有用，例如地理围栏或出口控制和数字版权媒体管理。

部署

图 4

The “Deploy” phase is responsible for incorporating a sequence of ‘pre-flight’ checks in order to ensure that the applications that are going to be deployed in the runtime environment conform and comply with organization wide security and compliance policies.

部署前置检查

部署之前应该对现状进行调研，检查以下状态：

• 镜像签名和完整性。
• 镜像的运行时策略（避免恶意软件和严重缺陷）
• 容器运行时策略（例如避免权限过高）
• 主机漏洞和合规控制。
• 工作负载、应用和网络安全策略。

可观察性和指标

把可观察性和指标引入云原生架构，能够提高安全方面的观察力，有助于解决和缓解异常情况；这个领域的工具能够收集信息并进行可视化展示。如果加入行为和启发式分析能力，团队能够检测到可疑事件、不明调用等异常行为并进行上报。AI、机器学习以及统计模型都是促进行为分析和启发式分析的手段。

应对和调查

应用应该提供日志，对认证、鉴权、行为和故障进行记录。开发人员应该在计划和设计阶段就开始这些工作。这些要素构成的证据链条，对于进行调查和根本原因跟踪时会非常有帮助。

对事故的应对和处理都需要进行取证，根据证据确定事件的根本原因，并为解决措施的实施提供反馈。容器环境的短暂性要求更灵活的工具集来对证据进行捕获和分析。将取证功能集成到事件响应计划和程序中，将提供获取和处理证据的方法，缩短确定根本原因的时间，并最大限度地减少损害风险。

运行时环境

图 5

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

计算

云原生计算的复杂性很高，并且还在持续演进之中。如果核心组件没有动用计算能力，组织就无法确保工作负载的安全。

Cloud native compute is a highly complex and continually evolving construct. Without core components to make compute utilization occur, organizations cannot ensure workloads are secure.

例如在共享主机上，用软件虚拟化环境运行的容器化多租户应用，这里使用面向容器的操作系统是非常有益的，这种操作系统是只读的，无关服务会被禁用。这样就很好地减小了攻击面；它还提供了隔离和资源限制，开发人员能够在共享主机内核上运行隔离的应用程序。为了增加防御纵深，注意不要让不同的数据敏感工作负载运行在同一个操作系统内核上。

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

操作系统提供了 crypto 库之类的系统组件，用于远程连接、进程启动、管理等的内核函数。操作系统是容器的基础，因此操作系统漏洞会影响到这些主机上运行的所有容器和应用。同时配置不当的容器也会影响到主机内核的安全，从而影响到该主机上运行的所有容器中的服务。

编排

任何编排系统都会有很多组件，这些组件被分成控制、数据之类的不同平面。有时会需要有上层建筑，负责在几个不同的的相互独立的控制平面上维持状态。

编排系统都会面对威胁，这些威胁可能影响部署的整体安全性和运行时的持续安全性。恶意访问编排 API、未经授权访问和更改键值存储、编排器仪表板控制集群、拦截控制平面流量、API 滥用、拦截应用流量等都是潜在的威胁领域。使用最佳实践和加固配置来防止暴露在这些威胁中是很重要的[^7]。另外，对初始配置的任何更改都需要在运行时进行监控和检测，以确保集群的持续安全。其他的安全最佳实践，如最小化对控制平面的管理访问、职责分离和最小特权原则等，都应该得到执行。

安全策略

编排器的安全特性和各种配置选项必须认真对待，要对容器运行时所生成的容器的特权需要严加管控。使用高层次的策略和治理构造可以强制执行这些安全限制。

资源申请和限制

通过 cgroups 在不同的对象层级使用不同的资源请求和限制，有助于防止工作负载有意（如 Fork 炸弹攻击或挖矿）或无意（如在内存中读取大文件而未进行输入验证、水平自动缩放导致计算资源耗尽）的耗尽节点和集群资源。

审计日志分析

审计日志分析是识别和关联系统入侵、滥用或配置不当的最成熟方法之一。持续的地、自动化德对审计日志进行分析和关联，对于安全团队来说至关重要。和传统应用对比，云原生架构能够为工作负载生成更精细的审计配置，更方便进行过滤。对日志的过滤能力， 能够避免下游处理机制的过载。与传统的日志分析一样，将日志中的数据关联/上下文转化为 “信息”，生成可操作的审计事件是重中之重，一次为基础来触发决策和进行事件响应。

违反组织政策的行为，会根据预先配置的一套规则进行过滤和识别。

为了能够对使用集群的实体的行为进行审计，启用 API 审计并对特定 API 或者动词进行过滤是很重要的。这些API 组或动词是安全团队、集群管理员或其他研究领域的团队的工作重心之一。攻击者可能会通过禁用日志或删除其活动日志来掩盖踪迹，为了制止这种行为，应尽快将日志转发到通过集群级凭证无法访问的位置。处理警报的系统应定期对假阳性报告进行调整，以避免警报泛滥、疲劳，并防止假阴性情况的出现。

控制平面认证和根证书

管理员应该配置所有的编排器控制平面组件，要求其使用双向认证，并且用周期性轮转的证书来进行认证，以此加固现有的控制平面。证书签发使用的 CA 可以是编排器自己的 CA，也可以是外部的。管理员应小心保护 CA 私钥。

Secret 加密

在容器编排或者部署环境中，可以在外部管理器或者编排器内部对 Secret 进行管理，介绍几个不同的保护方法：

• 使用外部密钥管理系统（KMS）加密
  • KMS 是一种保护 Secret 的安全方式，这种方式中，密钥在外部 KMS 中加密，KMS 回家米保存 DEK（Data Encryption Key），用 DEK 加密后的数据保存在 ETCD 中。这种方式有一个选项是把 DEK 缓存在内存中，减少对外部 KMS 可用性的依赖，并更快的在创建 Pod 的时候进行解密。
• 完全用编排器管理加密
  • 这种方式也会对 Secret 进行加密，但是密钥也同样由编排器管理。
• 不加密
  • 例如某些编排器会用 Base64 对 Secret 进行编码，然后直接存储在键值库中。

使用外部秘密管理器可以限制使用未加密的 Secret 的风险，并降低密钥管理工作的复杂性。多数情况下，这些工具会以 controller 或者 operator 的形式运行，从而在运行时透明地进行注入或者证书翻转。

容器

运行时

容器运行时的监控和保护，需要从进程、文件和网络的角度入手。容器中只能使用被许可的 Capability 和系统调用（如 seccomp）。对于关键挂载点和文件的更改需要被监控和阻止。对二进制文件、证书和远程访问配置的更改需要被制止，还应保证容器仅执行允许范围内的网络访问。此外，还应检测并拒绝指向恶意域的网络流量。

微服务以及杜绝隐式信任

微服务方式部署的容器化应用，其边界就是微服务本身。因此定义策略限制特定微服务之间的通信是有必要的。0 信任微服务架构能够在微服务受到威胁时，禁止横向移动，减少威胁半径。运维人员应该确保使用网络策略之类的能力来对容器间通信进行限制，仅允许被授权的东西向访问流量。NIST SP 800-204 中做了一些微服务安全策略的工作，可以作为实现安全微服务架构的指南。

镜像信任和内容保护

组织可以使用策略引擎仅允许运行保障被授权和签名的镜像，从而实现可信的可控的工作负载。另外加密容器允许对容器中的敏感代码、方法或者数据进行保护。

服务网格

服务网格在服务之间进行连接，并在连接中加入了流量控制、服务发现、负载均衡、韧性、可观测性、安全性等额外能力。服务网格中的微服务无需在应用层次实现这些能力，开发者可以聚焦在业务逻辑的实现上。为了有效地确保云原生服务之间的通信安全，企业应该使用服务网格的动态数据加密来消除 Pod 之间和工作负载之间的隐式信任。试用服务网格还能够解决身份问题，（云原生环境下）3 层、4 层、IP 地址的认证都已经无法有效反应工作负载的身份。服务网格不但提供了网络侧的隔离和安全，还在网络层提供了重试、超时以及断路器等服务治理能力。服务网格在工作负载级别上提供的授权能够增强访问控制方面的安全性。

服务网格能够减小云原生环境中的被攻击面积，并提供零信任应用网络所需的框架基础。

运行时检测

通过对已部署工作负载的监控，团队能够判断当前运行状态是否符合预期。组织应持续对环境进行安全扫描和监控，否则环境中的工作负载可能会变成攻击者的游乐场。使用工具对来自容器的系统调用和网络流量进行检测、跟踪、汇总和报告，来检测意外或者恶意行为。

虽然回归测试和安全测试可以帮助防止已知的、预期的问题被部署到生产环境中，但是要阻止的不止这些。应该对工作负载进行动态扫描，以检测之前未知的恶意行为。例如在工作负载运行了 X 天之后，改写的 Sleep 命令从 etcd 进行数据渗透，这样的行为在大多数环境中都是预期之外，因此不包括在安全测试中。工作负载中的木马，可能存在时间或事件方式的延迟，只有通过与基线预期进行比较才能检测到，这通常是在彻底的活动和扫描监控中才能发现的。

Functions

Serverless function 是很容易受到攻击的，必须进行适当的保护。限制进程只能执行白名单中的 Function，不允许进程更改关键系统挂载点等。

Function 必须进行限制，仅允许访问特定服务，可以使用网络或者授权模型来完成这个限制。另外 Egress 网络必须进行监控，管理员通过监控来检测或阻止对 C&C（Command & Conrol）以及其它危险网域的访问。Ingress 网络的监控则可以检查和移除涉嫌渗透攻击的恶意流量和命令（例如 SQL 注入）。

Serverless function 中，可供租户使用的控制措施相对有限。例如损坏的身份验证、不安全的依赖服务以及不安全的 API 集成都可能成为安全问题的根源。确定所有 Function 都在租户资源中，进行数据隔离都有助于解决这些问题，然而隔离环境可能因为资源受限造成性能受损。

Bootstrapping

要对计算节点进行初始化，建立信任数据，然后才能保障工作负载和配置运行在正确的节点上。这个过程检查计算节点的物理和逻辑定位，并为其提供认证。一般来说，云供应商的供给过程会完成这个工作，也会依赖第三方进行信任的检查。

存储

云原生存储涉及到很多技术，按照访问方式可以分为两类，一类是面向工作负载的存储（例如卷）包括块存储、文件系统等；另一类是通过 API 访问的存储，例如对象存储、键值存储和数据库。

存储系统包含是数据访问界面，其中定义了应用或工作负载存储以及消费数据的接口，这个接口可以通过访问控制、认证、授权和加密传输等方式进行保护。

存储系统还包含一个控制平面管理界面，它通常是一个受认证和 TLS 保护的 API，也可能有更细致的访问粒度。一般来说，控制界面只能由编排器或者服务管理员通过服务账号的方式来使用。

存储栈

存储解决方案都由多层功能组成的，这些功能定义了数据的存储、检索、保护，及其与应用程序、编排器和/或操作系统的交互方式。每一层都有可能影响和冲击存储系统的安全性。一个常见的例子是将文件或块持久化到对象存储的文件系统。包括提供对外访问能力的顶层之内的每一层，都是需要一视同仁进行保护的。

编排

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

系统拓扑和数据保护

要保护数据访问路径，和保障分布式拓扑中跨节点通信安全性，关键在于理解系统的存储拓扑。

常见的拓扑结构包括：

• 所有计算节点访问中央存储服务的集中式模型
• 将功能分布在多个节点上的分布式模型
• 以及将应用和存储工作负载结合在同一节点上的超融合模型。

要根据系统的拓扑模型来选择特定的、分层的安全机制，来保护存储中的数据和在存储位置之间传输的数据。

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

缓存

缓存层，通常是完全独立的系统，是为了提高存储系统的性能，特别是文件系统、对象和数据库的性能而实施的。缓存层是数据层的前哨，因此同样需要应用适当的访问控制和安全策略，

数据服务

存储系统通常会实现一些数据服务，一次提供额外的功能对核心存储功能进行补充，这些功能可以在堆栈的不同层实施，例如复制和快照（数据的时间点副本）。这些服务通常用于将数据副本移动到远程位置，必须确保相同的访问控制和安全策略也适用于远程位置的数据。

物理和非易失性存储

因为云原生功能可以在内部进行部署，云原生存储安全并不局限于虚拟的云原生架构。重要的是存储系统最终会将数据持久化在某种形式的物理存储层上，这种存储层一般是非易失性的。现代物理存储（如SSD）通常支持安全功能，例如根据 OPAL 标准进行自我加密，以及快速/安全擦除功能。当包含数据的设备需要离开安全的物理位置时（例如出现故障后要返回给厂商），安全擦除是很重要的。

存储加密

存储系统可以提供数据加密，从而对数据进行保密。传输中或存储中的数据都可以实施加密，当使用存储系统时，应确保加密功能的实现是独立于应用的。

加密是有计算开销的，因此会对性能产生影响，但许多系统上都有加速选项可以减少这一开销。在选择数据的加密种类时，要考虑数据路径、大小和访问频率，以及安全算法的法规要求或额外的安全保护措施需求。此外，团队在考虑架构的加密要求时，也同样应该缓存的加密问题。

传输中的数据（网络中的数据）和静止中的数据（磁盘上的数据）都是加密保护的目标。存储客户端或存储服务器中都可以进行加密，加密的粒度将因系统而异（例如每卷、每组或全局密钥）。在许多系统中，传输中的数据是用 TLS 保护的（TLS 的额外好处是通过证书提供一个认证层[^8]。旧的协议（如 iSCSI）可能更难保证传输中的安全（尽管可以使用更复杂的解决方案，如 IPsec 或加密的VPN[^9]）。静止状态下的数据一般使用标准的对称加密算法（如 AES）进行保护，并可采用特定的加密模式（如针对块设备的 XTS）进行部署。

加密功能通常依赖于和密钥管理系统的集成。

持久卷保护

要确保只有授权的容器和工作负载才能访问卷，就需要对持久卷的访问进行保护。首要措施就是为命名空间定义信任边界，以隔离对卷的访问。使用安全策略阻止容器组访问工作节点加载的卷，并确保只有合适的工作节点能够访问卷。尤其需要注意的是，特权容器能够加载不同命名空间中的加载卷，所以需要其它措施来进行保护。

指定卷的 UID 或 GID 仍然允许同一命名空间的容器访问，不会提供数据保护。NFSv3 会假设客户端已经进行了认证和授权，而不进行验证。在实施保护时，必须考虑认证和授权的发生点，以及是否存在该操作的验证。

制品仓库

制品库应该对 OCI 制品进行签署和核实。同样需要注意的是，缓存和发布工具也应该有这种能力，确保缓存层有能力检测篡改或者对数据集投毒的企图。

CNCF 存储白皮书提供了更多的云原生存储的概念、术语、使用模式等技术资料。

访问

认证和访问管理

一个面向云原生架构的全面的认证和访问管理（IAM）方案至少要提供服务认证能力。维护或者运营自建云、混合云的组织，需要进行用户和设备的身份管理。如果是多云环境中的应用和工作负载，身份联合是实现成功的关键因素。

应用程序和工作负载应该显示地使用双向认证的方式进行授权。由于云计算的短暂性，密钥轮换和寿命需要频繁而短暂，以维持敏态和控制的需求，在凭证发生泄露时，其泄露半径也能得到有效控制。

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

认证和授权必须在环境内部和整个环境中独立确定（决定点）和执行（执行点）。理想情况下，应实时确认所有工作负载的安全操作，在可能的情况下验证更新的访问控制和文件权限，因为缓存可能允许未经授权的访问（例如访问被撤销未在缓存中进行验证）。工作负载的授权是根据属性和角色/权限分配给它们的。强烈建议组织同时使用基于属性的访问控制（ABAC）和基于角色的访问控制（RBAC），以便在所有环境中和整个工作负载生命周期中提供精细的授权执行。这样的态势可以实现深度防御，所有的工作负载都能够接受、消费和转发终端用户的身份进行上下文或动态授权。这可以通过使用身份文件和令牌来实现。如果不执行这一点，就会限制组织真正对系统对系统和服务对服务的调用进行最小权限]访问控制的能力。

需要注意的是，在微服务的背景下，应用或服务身份也是至关重要的，应用的身份可能会被恶意服务欺骗和冒充。使用强认证系统和服务网格可以帮助克服这些问题。

所有工作负载和集群的控制过程，不管是人还是非人。都需要进行认证，他们的行动必须根据控制策略，对每个请求的上下文、目的和输出进行评估。为了简化认证过程，可以和企业功能（如多因子认证）进行对接。必须通过本节提到的访问控制机制进行授权。

凭据管理

硬件安全模块（HSM）

读者应该尽可能使用 HSM 这样的技术，用物理方式进行密钥保护。如果无法做到，则应该使用软件的证书管理器。

凭据管理周期

加密密钥数据应该由 HSM 或者基于软件的密钥管理系统生成。

Secret 的有效期应该尽可能短，超过期限后即宣告失效。为了达成“短寿”目标，密钥的生成机制应该是高可用、高易用的。如果使用了长效的 Secret，则应建立相应的流程和指导，定期进行轮换或撤销，特别是在秘密意外泄露的情况下。所有秘密都必须通过安全的通信方式进行分发，并应得到与其保护的访问或数据水平相称的保护。

在任何情况下，Secret 都应该在工作负载运行时通过非持久性的机制进行注入，这些内容不会在日志、审计、或者系统转储（例如环境变量）时泄露。

可用性

拒绝服务攻击和分布式拒绝服务攻击

云原生应用程序中的拒绝服务攻击是一种网络攻击。攻击者尝试破坏关键的云原生应用组件（例如微服务）、或者云原生应用赖以运行的编排层组件以及健康检测系统，让云原生服务无法正常提供服务。拒绝服务供给通常会通过项关键微服务或资源发起大量无效请求，引发系统过载的方式，来阻止系统的正常运行。

典型的分布式拒绝服务攻击会包含大量的入站流量，对云原生应用或者其依赖的上游设施进行冲击，这些流量来自大量不同的源头，需要在攻击到达云原生应用之前识别和转移流量，来缓解攻击造成的损害。

安全保障

从根本上来说，安全就是一个风险管理的过程，其目标是检测和解决系统风险。组织根据自身风险状况和容忍度来对系统进行持续加固，以期降低、转移或者消解风险。安全团队可以对组件进行评估，制定最小化、有弹性、功能正常的加固方案。例如团队决定更新基础镜像，应该对更新可能增加的额外端口、权限和软件包进行审查，接受、改变或进行限制。

而合规原则是一种控制原则，用来确定或创建需求，并根据需求对系统进行评估。评估结果是二进制的（通过或失败），但可能包含第 1 类（假阳性）或第 2 类（假阴性）错误，应视作 CI/CD 管线的测试结果进行评估。因此，合规性和安全保证是相辅相成且无法互换的过程。合规系统不能保证安全，安全系统也不能保证合规。

威胁建模

对于采用云原生技术的组织来说，对风险进行识别，并对识别结果进行控制和消解的主要机制就是对应用、数据流、支持流程和基础设施进行威胁建模。实现这一目标的方法与典型的威胁建模差别很小。以下指南是对 OWASP 威胁建模法的改进，建议用于云原生环境。

端到端架构

如果对个人或组织的云原生架构有了清晰的认识，就应该对数据影响进行指导和分类。这有助于团队根据架构进行数据的分布和其他保护机制的建设。云原生架构不仅仅是针对核心组件的，还应该包含源码、存储等所有软件开发周期中的其它元素。在对威胁建模时，这些相关因素都应该考虑。

威胁识别

在考虑针对云原生能力特定的威胁时，建议采用成熟的、使用良好的模型，例如 STRIDE 或者 OCTAVE。云原生架构的常见威胁包括但不限于如下内容：

• 通过社会工程方法窃取凭证，获取管理员身份。
• 篡改 API 服务配置文件或者证书，导致 API Server 重启，或破坏 TLS 认证失败。
• 禁用或配置错误的审计策略，导致对攻击行为缺乏证据支持。
• 如果攻击者破坏了正在运行的工作负载，成功进行渗透之后，就有可能造成信息泄露。
• 拒绝服务攻击能够导致没有资源限制的容器消耗整个节点的 CPU 和内存，导致节点离线。
• 特权 Pod 或者缺乏限制的安全策略，可能导致特权提升的后果。

云原生安全需要考虑的威胁者和已知的威胁模型是一致的：

• 内部恶意
• 内部无意
• 外部恶意
• 外部无意

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

利用管线和 IaC 可能对某些威胁产生消解作用，或降低其成功或发生的可能性。

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

威胁情报

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

事件响应

如果组织机已经具备了事件响应和分流机制，关注点应该放在如何将既有机制应用到云原生工作负载的问题上，云原生工作负载在节点隔离（Pod 会在不同节点上漂移）、网络（IP 地址动态分配）和不可变性（对容器内文件系统的更改通常会在重启后丢失）方面和传统流程的假设很不一样。因此需要重新评估这些假设并根据需要更新应用或者更新应对流程。观察工具和取证工具需要了解云原生应用的特点（例如 Pod 和容器），以便管理或重建受损系统。在一些编排系统中，因为将工作负载视为无个性的不持久的，证据的获取可能比较困难。另外要提到的一点是，从头构建事件响应和分流机制是可行的，但是不在本文范围之内。

安全堆栈

环境

预检安全工具

环境预检安全工具应最大限度地进行加固并确保遵守安全方面的最佳实践，同时最大限度地减少与托管环境、网络和协调层有关的权限。工具还应该确保合规性不会在运行时被破坏。

计算和节点检查

应利用工具确保计算资源的加固和安全性，例如用主机漏洞扫描器和 CIS 基准扫描器进行检查，通过后才能将资源标记为可以交付。

运行上下文

覆盖预检安全的工具适合作为 CI 管线的一部分，对文件、制品（例如容器）和 IaC 进行扫描。CD 管线中运行的安全工具更适合在特定上下文的特定配置中运行。

运行中的安全工具

工作负载和运行时安全

运行时安全工具可以分为四个关键的保护区域：

• 进程、容器或者系统层的安全
• 网络安全
• 数据安全
• 应用安全

每个保护区域都可以使用多种工具。策略引擎可以执行手动编写或者基于推荐系统的策略。策略一旦投入使用，这些工具将提供可预测的结果，并且可以在仅做监视、或者强制模式下使用策略。

威胁和漏洞信息可以让安全工具能够拦截来自未知威胁和已识别威胁的异常行为和安全事件。 这些信息通常会定期更新。 这些信息不但能够补充策略引擎的能力，还能实现为一个覆盖更大领域的防御工具。团队应该关注网络威胁情报中已知的 C&C 服务器、挖矿域名、恶意软件校验和等信息，从而有目的的更新策略工具。

尽管现有工具可以提供机制来管理由误报和误报问题产生的噪声并处理已知威胁，并使用策略驱动的防护来规范操作，但基于机器学习（ML）的安全工具提供了已知和未知威胁的检测层，超出了可预测工具可以建立的范围。 例如，对基于身份的授权日志进行基于行为的分析，以检测内部威胁和破坏，或者对编排器审计日志进行自适应分析，以检测服务帐户的试探和盗用行为。 机器学习驱动的主机系统调用模式分析可用于检测容器逃逸尝试，或主机爆破尝试。

用于监控和跟踪云原生编排器的安全工具通常以特定领域的商业产品的形式提供，其中会包含跨越多个领域的强大功能，例如策略控制、合规检查、基于 AI/ML 的异常检测和良好的集成接口。

和工作负载一样，用云原生方式实现的用于监视，报告或控制环境安全性的工具会更加便于使用，管理和部署。

零信任架构

零信任架构通过细粒度拆分、微边界的架构，并通过执行策略限制消除数据、资产、应用程序和服务的隐式信任，从而减轻了网络威胁横向扩散的可能性。零信任架构的最常见实现方法是依赖于加密概念的。首先要用硬件或者令牌来保护特定的密钥信息，并且能够用安全的方式和平台进行通信。

零信任架构通常由几个部分组成：

• 每个实体都能创建自己的标识
• 每个实体都能独立地认证其它实体（例如用公钥体系）
• 实体之间的通信是加密且不可篡改的

零信任架构以信任根来创建零信任的各个组成部分：给实体或者进程绑定防篡改的信任能力，构成框架的基础成员。 然后需要实现自证、验证、和证明实体身份的能力。例如对于容器服务的来说，如何检查该容器是否是它声称的身份？ 这需要使用编排器进行验证，但是要信任编排器，我们需要确保其不受干扰地运行，只有它在运行受信任的操作系统和 BIOS 等基础设施上的时候，才能确保这一点。这实际上也是一个信任链条。

零信任架构也需要实体之间的通信安全。网络分段能为零信任架构提供帮助，值得考虑，但这并不能覆盖零信任的需求。编排器的网络策略以及服务网格都是全面的零信任方案组件。网上有更多零信任相关概念的相关信息。

最小权限

最小权限原则非常重要，某种程度上说，是云原生架构中最重要的一方面，这个技术栈的所有层面在进行认证和授权的设计实现过程中，都需要考虑这个原则。传统的最小权限原则是在账户层考虑的，这个账户可能是人，也可能是服务。

云原生环境中，应该在堆栈的每个层次使用最小权限原则。在评估负责每个层次的工具时，也应该考虑到这一点。在探索各种产品和能力时，会发现很多容器缺省就是特权模式的，或者是要求 root 权限进行运维的。因此可能需要一些额外的隔离措施来运行这些特权负载。组织需要考虑对不同特权的领域进行隔离，在工作负载和部署中采用最小权限模式，可能包括从 cgroup 和系统调用，到制品管理和非 root 构建等多个方面。

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

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

角色和责任

在转向云原生架构和部署时，组织应该对传统安全角色和责任进行调整，并创建云原生特有的新安全角色。随着现代开发方法论的快速发展，以及 IT 活动与业务需求的更好结合，安全工作必须具有适应性、具备应对实际风险相匹配的能力和透明性。期望开发人员和运维人员成为安全专家是不合理的。安全从业人员需要与开发、运维和其他项目角色合作，使安全和合规性的执行和开发生命周期充分结合。开发人员使用的工具就能实时报告发现（安全）问题，并像处理构建失败一样去解决问题。

在云原生环境中管理安全性时，在 DevOps 环境中经常出现界限模糊的情况，这里还是应该进行明确的职责分离（SoD）。尽管开发人员将更多地参与实施和执行安全措施，但他们无需设置策略，也不必了解角色所不需要的区域等。应根据组织的风险承受能力和业务实践，在角色之间、产品之间和应用团队之间进行职责分离。可以理解，小组织中的个人会履行许多职责以保持业务蓬勃发展时，这种分拆可能很困难。然而，随着组织的不断发展，个人的认知也会发生变化，实施不同角色的权限让个人能够发挥独特作用，也有助于执行 SoD。最终将重组角色重新分配给新的成员，但是不会为新角色增加范围。

随着产品和服务迁移上云，组织将需要重新评估其资产风险。 随着使用中的技术及其部署堆栈的所有权和管理方面的变化，管理人员会面临风险态势的急剧变化。资源提供者和团队之间的共同责任将要求更改风险接受、转移和新的缓解机制的阈值。

合规

系统应当具备一定安全控制措施，能够应对监管和合规性指导，让云原生资源更加安全。这样做还可能使相关监管机构和审计人员的工作过程变得更加方便，系统甚至可以通过设计和规划，最终使用插件模式实现对各种监管机构的自动合规。虽然合规性通常需要利用安全基准来提高安全性和配置管理的执行力，如 CIS 基准，还是建议使用机器可读的合规性控制框架和语言。

监管审计

金融、卫生、政府等行业需要遵守特定的要求来进行系统保护。用户信任这些系统和他们的交互是安全的和私密的。每个组织都应该评估适用于自己的监管标准（例如 PCI-DSS、HIPAA、FedRAMP、GDPR 等），然后要确定如何把具体需求落地到自己的云原生系统之中，以及如何在现实世界中实施这些标准。这种支持特定标准的证据收集机制应该尽量通过不可抵赖性的环节来实现自动化。

角色和用例

重点是安全、保护、检测和尽可能的自动响应。它不一定是单独的开发工具，而是透明地集成到开发流程中的安全工具，以执行安全策略，在此过程中可以进行快速反馈和最直接的补救行动。有关云原生安全用例的具体信息，请参考 [SIG-Security 的用例列表]（https://github.com/cncf/sig-security/blob/master/usecases.md）。

业界

企业

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

微型企业

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

金融

金融行业关注的核心领域是未经授权的信息披露、欺诈和资金可用性，这对成功采用云原生技术至关重要。欺诈会直接影响资金的可用性，因此金融交易的完整性是头等大事。

医疗

医疗保健行业关注的核心领域是未经授权的信息披露、记录的及时性和可用性以及记录的准确性，这些都是采用云原生技术成败的决定性因素。由于医疗行业的性质和实践，记录及其相关内容的可用性是做出医疗决策的基础。在没有这些信息的情况下，就会形成新的记录。

学术和教育

教育机构成功采用云原生技术的核心关注领域可能取决于预期的最终用户。面向未成年人的机构可能有额外的法律要求，以保护未成年人的机密性，因此要重视访问控制能力。除此以外，各机构应关注教育内容对终端用户的可用性。

公共领域

公共部门组织关注的核心领域是安全、数据主权、合规性和供应商锁定，这些领域对于成功的云原生至关重要。这些障碍来自于机构为保护公共利益而制定的法规。在公共部门，保持公共和政府实体之间的和谐和信任是必须保障的。此外，部署和功能的及时性也可能是一个强有力的考虑因素。采用云原生，加上现代方法论，可以提高组织效率，这对公共部门的许多领域会产生极大促进。

云原生安全的演变

容器技术是一个不断发展的领域，得到了广泛的应用。云原生技术的威胁状况以及在缓解和解决这些威胁的方法也在不断变化。除了安全容器平台的复杂生态系统外，这些都需要一个全面制定、深思熟虑的安全策略，并对安全策略的执行、响应和操作纪律进行技术控制和自动化。

如果实施得当，容器可以提供巨大的安全优势。它们提供了更大的透明度、模块化、减少攻击面、更容易的应用组件更新以及应用组件运行的一致环境。这种一致性使得并行安全能够在开发、测试和生产运行环境中茁壮成长。它们还可以减少企业范围内安全事件的影响，当实现应用程序之间建立的适当隔离时（基本上可以在可能拥有扁平网络的企业中实现微观分段），作为分层防御-深度安全策略的一部分。

在当前安全方面的所有挑战、所需安全工具的数量以及市场上技能和人才的短缺，确保容器平台的安全是一个巨大的挑战。我们预计，随着云提供商提供的容器服务产品越来越成熟，在互不兼容的规范上集成了更多的云原生安全与智能工具，我们将看到更多的迁移到云端。这些产品作为共同责任模式的一部分，最终会降低企业的开销。

因此容器的采用、以及云原生的采用，将继续推动企业的数字化转型进程。企业已经开始尝试 Serverless 架构和设计来提供一些服务，但考虑到在编排 Function 构建业务功能时，可视性降低的挑战，以及现有的大量尚未知晓的安全挑战，使用 Serverless 构建整个业务功能仍在发展阶段。简而言之，随着服务提供商的安全控制以类似于现有容器生态系统的方式减少消费者的开销，Serverless 在云原生架构中的应用预计将随着时间的推移而增加。

然而，威胁状况总体上保持不变，顶级弱点始终被同一组攻击者利用。我们看到的最显著的变化是攻击者针对云原生组织和应用采取的攻击方式和机制。任何针对容器编排者和部署的攻击都在增加，这一点从通过渗透或木马镜像进行的挖矿行为可以看出。与任何开始达到市场饱和的创新技术一样，攻击者会利用任何可用机会。

随着这些攻击变得更普遍、更复杂、更扩大，云原生安全必须不断发展，企业和 DevOps 团队需要更加重视。我们看到安全策略即代码的案例越来越多，但在安全策略的执行、检测和响应方面，还有很大的演进和增加自动化的空间。很明显，即时和自动化的安全智能和响应将是挫败攻击，甚至从攻击中自我修复的关键。甚至可能在§[^9]发生时进行调整和整合。

容器取证工具和技术将需要不断发展，以跟上云原生的发展方向。这一点尤为重要，因为在基础设施即服务和其他即服务模式的背景下，事件的数量和复杂性都在增加。

结论

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

处于技术鸿沟边缘或早期多数的组织，应认真分析和应用核心安全概念，以缓解加固和环境控制的滞后现状。

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

这些核心安全概念是：

• 防止未经授权的访问（个人和非个人实体）通过持续地从已知的良好状态重新建立基础，减少资产对未经授权实体的暴露。
• 不变性以保持内容和代码的完整性。
• 服务、工具和内容的可用性——分布提供弹性和冗余。
• 审计和问责——提供了一个机制来确保合规，并跟踪授权的变化。

参考

NIST 800-204 Security Strategies for Microservices-based Application Systems

NIST 800-190 Application Container Security Guide

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

Threat Modeling: 12 Available Methods

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

NIST Application Security Container Guide, Center for Internet Security (CIS), NIST Security Strategies for microservices and OpenSCAP benchmarks exist for Docker, Kubernetes, and several managed Kubernetes distributions.

MITRE ATT&CK Matrix For Kubernetes

致谢

This white paper is a community effort driven by the members of the CNCF Security-SIG. Thank you to everyone for their outstanding contributions. Special thanks to Emily Fox and Jeyappragash JJ.

Contributors:

• 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 - Independent
• 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

Reviewers:

• @justincappos
• @lumjjb
• @whaber
• @craigbox
• @anvega
• @magnologan
• Alok Raj - XenonStack (alok@xenonstack.com)
• @nyrahul
• @ranio1
• @lizrice
• @justincormack

[1^]: Another model to consider is Cloud, Clusters, Containers, and Code: https://kubernetes.io/docs/concepts/security/overview/

[2^]: Example - MITRE ATT&CK Framework for Kubernetes

[3^]: Shifting security left often leaves organizations to lapse operational security monitoring. It is important that security exists in all parts of the lifecycle and organizations continually evaluate other aspects of their business and technology processes where they may reach beyond modern security paradigms to embrace security as a culture and habit.

[4^]: Human capital is a vital asset necessary to the success of any organization, the corresponding intellectual property and relational capital brought as a result is equally in need of protection.

[5^] https://blog.aquasec.com/malicious-container-image-docker-container-host

[6^]: According to Applied Software Measurement, Capers Jones, 1996 and adjusting for inflation - 85% of defects are introduced during coding with a cost of $41 to fix compared to a post release fix cost of $26,542.

[7^]: cisecurity.org maintains a listing of benchmarks for hardening

[8^] It is critical to note that while authentication is available for use, mutual authentication is the preferred mechanism to not only verify the client but also the server (outsider versus insider).

[9^]: Utilization of a VPN does not guarantee encryption.

[10^]: The concept of regression proofing is best explained as a facet of antifragile behaviors within technology environments. Instead of remaining resilient and robust against adverse conditions and attacks, technology can proactively adapt and thrive when subjected to them.