下载掌阅APP，畅读海量书库
立即打开
安全是企业进行云原生化改造时关注的核心问题，也是本书介绍的eBPF技术的应用领域。在介绍eBPF技术之前，需要先了解云原生给传统企业架构带来的挑战，以及云原生安全的演进、理论基础和体系架构。
云原生是什么？在了解云原生安全之前，我们先来看一看云原生的定义。下面是来自云原生计算基金会（Cloud Native Computing Foundation，CNCF）的官方定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。”
各云服务商和研究机构对云原生也有自己的定义。从技术角度出发，云原生包含松耦合、弹性可扩展的分布式架构，标准化、自动化的组织和开发流程变革及蕴含无限按需计算能力的动态基础设施。从广义上说，云原生是帮助用户获得云计算在性能和成本上最大红利的软件开发方式，包括因为云计算的引入而带来的技术、文化、组织架构和方法论的认知升级等，而包括云原生安全在内的服务化的云原生产品也都可以包含在这个因云而生的范围内。
对于使用云原生的用户来说，安全一直是企业上云首要关切的问题。随着云原生对云计算基础设施和企业应用架构的重定义，传统的企业安全防护架构也面临着新的挑战。比如传统的基于边界的安全模型中对静态标识符（比如IP地址）的依赖在云原生场景下不再可行，需要企业安全防护更接近基于属性和元数据（比如应用标签等）识别不断变化的动态负载，并采取对应的保护措施，同时要求安全体系能够自适应云原生应用的弹性规模，这些转变都要求在企业应用生命周期和安全设计架构中实施更多自动化的安全控制，在身份体系、资产管理、认证、鉴权、威胁分析监测和阻断等安全架构设计上都需要做出对应的云原生化改造。攻击者针对云原生平台和应用的攻击手段还在不断进化中，但是威胁发生的场景总体可以分为云原生平台基础设施、DevOps软件供应链和云原生应用范式三大类。
容器编排架构是云原生应用部署的核心引擎，也是云原生平台基础设施的关键组件。容器技术基于Linux内核namespaces和cgroups等特性，从安全防御角度看，容器技术给整个系统架构引入了新的攻击层，攻击者可以利用操作系统内核漏洞、容器运行时组件和编排系统组件的安全漏洞及不当配置发起多个维度的针对性逃逸和越权攻击。而近年来Kubernetes、Containerd、Istio等云原生核心社区项目也爆出了不少高危漏洞，这些漏洞给攻击者提供了可乘之机，也侧面说明了云原生平台基础设施组件已经成为攻击者重点关注的目标。
与此同时，云原生平台层组件相较于传统架构引入了更多的配置项和隔离层，这就给企业安全管理运维人员提出了更高的运维要求。如何保证平台基础设施层的默认安全性，如何在遵循最小化权限原则的基础上进行授权操作，如何建立云原生应用系统的安全审计和监控能力，这些新的挑战的应对之策都需要云服务商和企业安全管理运维人员协同构建并最终实施到企业云原生化转型后的系统应用架构中。
云原生弹性、敏捷和动态可扩展等特征极大地改变了传统应用的部署模式，应用自身的生命周期被大幅缩短，云原生应用的生命周期通常是分钟级，而云原生可编程和不可变的基础设施支持应用制品的快速构建、部署和更新，也极大提升了企业应用的迭代效率。
在传统的软件开发流程中，安全人员通常是在系统交付之前才开始介入并进行安全审核工作的，这样的安全措施显然已无法满足云原生时代软件供应链的快速流程。也就是说，采用DevOps可以有效地推进快速频繁的开发周期（有时全程只有数周或数天），但是过时的安全措施则可能会拖累整个流程，即使较高效的DevOps计划也可能会放慢速度。为此，来自Gartner的分析师David Cearley在2012年首次提出了DevSecOps的概念。相较于传统的软件开发安全流程，DevSecOps强调从企业安全文化意识、安全流程左移及构建全链路的自动化流程等方面来加固新时期下的企业软件供应链安全。Gartner预测，到2025年将有60%的企业采用DevSecOps和不可变基础设施。
云原生促进了服务网格项目的飞速发展，也让微服务架构在云原生应用架构下更加普及。在微服务架构下，服务之间的网络流量更多使用东西向，传统架构下基于南北向流量的安全边界防护模式已经不再适用。另外，服务之间需要更加细粒度的身份认证和访问控制，单点的不当授权配置可能引发全局维度的越权攻击。与此同时，微服务暴露的大量API也可能暴露更多的风险面，诸如数据泄露、注入攻击、DoS攻击等风险屡见不鲜。微服务应用引入了大量的开源软件和管理面组件，其中不断爆出的高危安全漏洞也是威胁整个系统安全的关键。
除了微服务架构，云原生还推动了Serverless和函数计算等技术的蓬勃发展。一方面Serverless和函数计算帮助屏蔽了K8s等云原生应用编排系统复杂的管理运维门槛，另一方面也让安全、弹性、可用性等云原生关键特性需求下沉到云服务商基础设施层实现，进一步降低了企业在应用层面的运维负担。与此同时，需要云服务商在基础设施层面具备相匹配的安全隔离和监控能力。
应用的容器形态改变了传统模式下基于节点和进程维度的安全运营与资产管理方式，随着云原生存储、网络及异构资源利用率等计算能力的提升，应用在节点上的部署密度也以指数级提高，需要新的运行时安全监控告警和资产管理模式与之对应。
鉴于上述安全挑战，可以说以云原生为背景的安全工具和技术有巨大的需求与市场，同时企业普遍缺乏具有相应安全和云原生专业背景的人才。而随着企业云上应用云原生化改造的持续进行，可以说云原生架构注定会在很长一段时间继续成为攻击者的重点攻击渗透目标。与之对应，云原生安全的发展势在必行，其中以eBPF为代表的核心技术手段势必会在云原生安全防御体系中扮演越来越重要的角色。
面对快速变化的挑战和迫切的市场需求，云原生安全的发展机遇与挑战并存。企业的投入是最能直接反映云原生安全发展的标尺，据Paloalto 2022年在全球范围的云原生安全调查报告，伴随着企业云上规模的逐年增长，构建系统的全面纵深防御、合规需求及云上转型的技术复杂性一直是近年来调查结果中最为关键的3个核心问题（见图1-1），而企业客户对于安全合规的关注更是呈逐年上升的趋势。
图1-1 企业上云面临的关键挑战
（来源：Paloalto《2022年云原生安全报告》）
在降本增效的大环境下，企业对于云上安全的投入保持着稳步增长的趋势，调查显示，2020年只有4%的受访企业在安全预算上超过了企业云上整体投入的20%，而到了2021年，这个数字已经提高至15%，如图1-2所示。
图1-2 在安全预算上超过企业云上整体投入20%的企业比例
另一个比较有意思的数据是企业使用的云安全产品供应商的统计，首先使用5个以下安全产品供应商的企业从2020年的41%提升到2021年的68%，而使用6～10个安全产品供应商的企业从2020年的39%下降到20%。这里一个很重要的原因是云原生安全产品的体系化整合，另外企业内部DevSecOps和安全自动化治理上的发展也有助于企业自身的安全运维更加统一化、体系化。
在企业上云并进行云原生化改造的初期阶段，DevOps是被广泛接受的概念，开发团队开始更新自身业务应用的开发流程管道，而安全团队很快意识到其工具并不适合以开发者驱动、以API为中心且基础设施无关的云原生安全模式。因此，不少以云原生安全为背景的安全应用开始进入市场，初期这些应用产品多是为了解决供应链生命周期中部分堆栈的问题而开发设计的，但就其本身而言无法系统地管理和报告整个云原生环境的安全风险，这就迫使安全团队在多个安全供应商提供的应用工具之间周旋，不仅增加了成本和系统复杂性，也引入了额外的风险点。随着云服务商和一些头部云安全厂商不断完善在云原生安全方向端到端的安全能力体系，企业在云上生产环境实践DevSecOps和自动化安全治理的进程加快了。
Paloalto的报告也显示，在自身软件供应链环节完成DevSecOps高度集成的企业出现因安全而导致的项目延期或利润降低等问题的概率是没有集成DevSecOps企业的九分之一。另外，RedHat在2022年的Kubernetes安全报告中也显示，已经有78%的受访企业正在开始或已经完成DevSecOps的深度集成。
自动化安全治理一直是企业系统化提升安全水平的重要方式。结合云原生的应用特点，自动化安全治理可以为企业的安全运维人员提供一个全局可视化的安全资产管理系统，该系统可以通过自动化的检测机制在企业应用构建与部署的关键点扫描镜像和应用模板中的安全风险，同时帮助发现开发运维人员在应用控制面的不当配置，阻断可能威胁系统安全的变更操作，并及时审计和通知上报应用运行时的威胁事件。在Paloalto的调查中，实现高度自动化安全治理的企业在内部安全事件的投诉率上普遍低于自动化在中低档位的企业的三到四成，同时在内部安全满意度的调查中明显高于其他企业。
在国内，中国信息通信研究院（以下简称信通院）2023年对云原生技术应用挑战的调研显示，安全性连续两年成为企业用户的最大顾虑，在2021年的调查中（见图1-3）大部分企业用户已经认识到云原生安全能力建设的重要性，近七成的受访企业计划在未来一年内提升自身云原生环境的安全能力。
同时，在对企业用户最关心的云原生安全问题调研中，容器和微服务相关安全问题排在前5名，如图1-4所示，其中容器运行时安全是企业用户最迫切的需求，超过一半的用户关心容器逃逸问题，而基于eBPF的云原生运行时安全正是本书关注的主要方向。
图1-3 未来建设云原生安全能力计划
（来源：中国信息通信研究院《云原生用户调查报告》）
图1-4 企业用户最关心的云原生安全问题
（来源：中国信息通信研究院《云原生用户调查报告》）
在海外，以云原生安全为背景的安全防护实践已经经过一定时间的积累。在CNCF开源项目全景图中，以云原生安全为背景的开源项目和公司数量都在持续增加，其中如Falco、Tetragon等基于eBPF技术的云原生安全明星项目在后续章节中会重点介绍。
与此同时，以云原生安全为背景的合规标准也先后落地，比如美国国家标准与技术研究院（NIST）在2017年最早发布的《应用容器安全指南》，解释了与容器技术有关的安全问题，并为云服务商和企业规划和实施运维容器提出了切实可行的指导建议；在2022年，针对云原生安全技术的发展趋势，NIST又提出了服务网格场景下针对微服务应用的DevSecOps实施指南，从云原生应用编码、应用服务编码、基础设施即代码（Infrastructure as Code）、策略即代码（Policy as Code）和可观测性即代码（Observability as Code）5个层面来指导企业将对应的安全措施应用到更加敏捷和快速迭代的软件生命周期中去。另外，美国政府联邦风险和授权管理计划（FedRAMP）在2021年发布了《容器漏洞扫描要求规范》，规范中描述了对使用容器技术的云系统进行漏洞扫描的特定流程、架构和安全考量，并从合规层面约束全部联邦机构实施。
在云原生安全合规标准中，不得不提到的是CIS Kubernetes Benchmarks，它是由非营利组织CIS（Center for Internet Security，互联网安全中心）结合众多服务商安全领域专家的建议定制发布的Kubernetes领域的最佳安全实践，可以帮助使用者在基于Kubernetes部署生产环境前进行相关的安全配置加固。除了基于开源发行版编写的通用合规准则，各头部云服务商也结合自身Kubernetes容器服务的产品特性定制化了服务商适配版本。标准中包含了对Kubernetes集群管控面节点和组件、etcd、数据面worker节点的详细安全配置规范，以及每条规范对应的威胁等级和影响最终扫描结果的评分标准。一些云服务商和开源社区也提供了基于CIS规范的基线扫描工具，以帮助用户完成对集群基础设施安全配置的基线扫描并给出加固建议，关于规范的详细内容可参考CIS社区的官方文档。
在合规标准之外，随着云原生相关技术栈的迅速发展，需要有一个体系化的方法论来概括云原生安全架构。为此，CNCF相继推出了《云原生安全白皮书》的v1和v2版本，进一步为云原生安全架构体系和方法论提供了相关指南。在国内，信通院联合业界数家在云原生安全领域有深入研究的云服务商或安全厂商，在2021年发布了《云原生架构安全白皮书》。白皮书从云原生基础设施安全、云原生计算环境安全、云原生应用安全、云原生研发运营安全、云原生数据安全、安全管理6个主要方向，全方位、系统化地剖析了云原生架构安全防护体系（见图1-5），为国内企业在云原生化转型过程中构建自身架构的安全防护体系提供了标准化的指导意见。
1.4节会基于两部白皮书的内容框架对云原生安全体系方法论做进一步的阐述。
图1-5 云原生架构安全防护体系
（来源：中国信息通信研究院《云原生架构安全白皮书》）
正如云原生概念在狭义和广义上有不同的定义一样，云原生安全亦是如此。从狭义上，可以将云原生安全理解为基于云原生架构和技术背景建立的安全防护手段，比传统安全模式更加灵活地适配解决云原生架构下的安全挑战；从广义上，云原生安全是因云而生的，是深度融合了云基础设施并能够充分发挥云原生效能优势的安全系统。本节将基于云原生应用系统特性，融合传统安全体系方法论介绍云原生安全的理论基础。
安全在本质上是一个发现、定位和管理系统风险的过程。对于企业应用而言，安全需求分析、安全测试、安全开发和反复的加固措施也同时伴随着应用迭代，而威胁建模可以在应用设计开发的早期阶段帮助识别应用架构中潜藏的可能引发安全风险的设计缺陷，同时给出相应的安全建议，进一步提升设计开发人员的安全意识和能力，帮助构建企业DevSecOps流程，协同安全、运维、业务开发团队有效降低企业的安全成本。
已经应用云原生技术的企业应该如何定义、管理和规避安全威胁？核心是构建一个端到端的系统架构，架构中需要包含重要的组件交互流程、数据存储方式和安全边界。架构中的组件不仅是一些核心的功能组件，还需要考虑应用生命周期的开发、构建、测试和发布等涉及的所有流程中的关键组件，这样的端到端系统化架构可以由熟悉系统全局的业务架构师和安全团队共同完成。一旦边界和系统中组件的数据交互流程被构建出来，下一步就可以基于不同的威胁模型和情报进行系统建模，尤其需要注意的是跨安全边界的交互。
1.威胁识别
威胁建模理论的发展已经经历了很长的时间，我们可以基于如STRIDE或OCTAVE等成熟框架来构建威胁模型。云原生应用常见的威胁如下。
❑仿冒：攻击者利用泄露的有管理员权限的集群访问凭证发起恶意攻击。
❑篡改：通过篡改集群管控组件参数或通过修改集群apiserver证书等关键配置使集群管控组件无法启动。
❑抵赖：因为没有启动或错误的审计日志，导致无法为潜在的攻击提供证据。
❑信息泄露：攻击者入侵了集群中正在运行的工作负载并窃取了用户信息。
❑拒绝服务：集群中部署了没有定义资源限制的工作负载，攻击者可通过恶意行为消耗整个节点的计算资源，最终导致节点失连。
❑权限提升：攻击者可以利用集群中部署的特权工作负载或通过篡改安全上下文来提权发起进一步的逃逸攻击。
而云原生安全中需要考虑的威胁行为实体如下。
❑内鬼：具有恶意企图并且在建模系统内有权限执行恶意操作的企业内部人员。
❑内部不知情者：在建模系统内有权执行操作的内部人员（假设任何人都可被欺骗）。
❑外部攻击者：在系统外部的恶意攻击者，可以在没有明确授权的前提下利用网络、供应链、物理边界等漏洞对建模系统发起攻击。
当然还有其他可能的行为实体（比如不知情的外部人员），这里没有列举是因为他们的行为影响范围是上述列举实体的子集。
由于云原生技术架构的复杂性，容器技术、编排引擎等核心组件都可能给整个威胁系统引入新的风险，需要企业安全人员在传统基础设施架构威胁之外从社区等途径尽可能全面地获取安全威胁信息。同时由于云原生加速了应用迭代效率，意味着在架构动态变化的同时，需要重新评估当前威胁建模下的安全机制和模型矩阵，看它们是否也需要随之调整。
2.威胁情报
威胁情报是关于已知威胁的广泛信息，用来帮助企业安全管理人员更快速、更明智地进行决策，并且鼓励在对抗攻击时采取主动而非被动行为。
如前文所述，云原生架构下的应用制品会依赖众多第三方软件包，同时容器运行时和编排层框架也包含了复杂的组件。这就意味着威胁情报必须涵盖云原生编排引擎、运行时、核心组件和安全社区等更加广泛的威胁来源，从而能够更加准确地描述云原生攻击类型、攻击路径，并识别攻击影响和范围。
ATT&CK框架是网络攻击中涉及的已知策略和技术的知识库，其中针对容器和Kubernetes的ATT&CK攻防矩阵面向云原生和容器场景，详细描述了攻击者在云原生和Kubernetes环境中发起攻击的过程与手段，可以帮助企业构建容器化应用安全体系，提高云原生容器安全水平，也是企业构建云原生威胁情报体系可以利用和借鉴的基本框架，如图1-6所示。
整个威胁矩阵由不同的行和列组成，其中行代表攻击技术，列代表攻击战术手段，从左至右代表一个通常的容器侧攻击路径。对矩阵中各攻击技术的概要说明如下：
❑初始访问。这是攻击者利用集群环境发起攻击的第一步，企业内部云账号认证凭证、集群kubeconfig访问凭证及主机登录凭证等关键密钥的泄露有可能让攻击者直接获得初始访问权限，集群暴露了未授权访问端口和系统内应用漏洞，也有可能成为攻击者可以利用的突破口。
图1-6 阿里云容器安全ATT&CK攻防矩阵
❑执行。在成功获得集群访问权限后，攻击者需要继续执行恶意代码发起进一步的攻击，这样的后门程序可以通过创建源自恶意镜像的容器负载或通过客户端工具远程登录到容器内部完成执行。
❑持久化。攻击者还需要通过部署恶意控制器、执行后门程序的定时任务或直接通过特权逃逸到主机侧修改控制平面组件和授权配置等方式进一步获取集群控制权，进而固化攻击方式。为此，集群中需要通过策略治理等手段约束可以在集群中部署的可信仓库列表，以及严格限制集群中部署工作负载的特权配置，同时对容器中的异常行为进行实时监控告警。
❑权限提升。在集群容器环境中，攻击者有多种手段试图逃逸并最终获得主机甚至集群的最高权限。作为集群的安全管理人员和集群应用的开发者，需要严格遵循最小化权限原则来设置应用负载的安全配置，不给攻击者可乘之机。
❑防御逃逸。当攻击者入侵成功并获得了集群控制权后，会主动逃逸系统的安全防御监测。比如清理集群审计日志、使用系统组件名称伪装和混淆等增加安全运维的难度。而企业安全人员可以通过对主机上执行的Shell命令或exec进入容器后执行的调用行为进行安全审计，来发现类似的攻击行为。
❑窃取凭证。凭证是攻击者可以利用的直接武器，当攻击者成功入侵后，一定会通过各种手段尝试获取集群Secrets、高权限Service Account、云账号AK等，作为发起进一步攻击的凭证跳板。而集群应用环境中的密钥安全管理和签发短时凭证是防止攻击者窃取凭证的有效手段。
❑探测。除了窃取凭证，攻击者还会试图通过访问集群apiserver、kubelet或通过内网扫描等方式了解集群中的可用资源和授权信息。此时，对集群apiserver或相关网络服务的调用审计可以帮助企业及时发现可疑的探测攻击。
❑横向移动。指攻击者在侵入容器后进一步逃逸攻击主机侧、集群甚至整个云账号的攻击方式。限制集群应用容器的系统特权、收敛容器中的token权限、最小化集群授权等安全加固措施均可增加攻击者横向移动的难度。
❑影响。到了这个阶段，以破坏为目的的攻击者可能通过劫持资源、DoS攻击、加密勒索等手段直接影响了系统可用性。企业应用需要部署完备的运行时安全检测来响应攻击，同时默认对工作负载配置应用软硬资源限制，以降低事件影响。
“木桶的最大容积取决于最短的一块木板”，云原生安全同样遵循这样的木桶原则。由于云原生技术栈的复杂性，企业安全管理和运维人员更需要在安全准则的指导下，全面、充分地了解全局安全风险，提升系统“最低点”的安全水平。
1.默认安全
默认状态下的安全性是整个系统安全体系的根基，不仅决定了生产系统的稳定性，也直接关联了上层安全方案的运维和实施成本。实现系统的默认安全需要遵循如下原则：
❑将安全性融入设计要求。在系统设计阶段，安全性就应当作为基本且必要的需求融入进去，并在安全专家的指导下审核架构设计中隐藏的风险。结合前文提及的威胁建模理论，将红/蓝/紫军的攻防演习自动化集成到软件供应链管道中，在业务和安全团队的协同配合下不断优化安全设计。
❑基于最佳安全实践设置系统配置。安全运维人员应当在最佳实践的指导下初始化应用系统的默认配置，而对于云服务商来说，这样的初始化配置方式应当以一种简单、透明的方式提供给终端用户，在屏蔽后端复杂实现的同时也需要考虑额外的配置成本。如果这些安全功能和配置项对终端运维人员设置了过高的门槛，或缺乏必要的文档说明和自动化API，那么就需要重新优化实现。
❑谨慎使用不安全配置。对于系统中可能增加安全风险的配置，需要告知用户并明确提示风险，让用户在知晓风险的前提下有意识地开启不安全配置。
❑针对线上应用提供安全加固选项。已经发布上线的应用系统中可能存在已知的安全设计缺陷，此时加固应用配置很可能导致兼容性问题，影响线上业务的稳定性，需要加固方案具备兼容性和可逆性，保证应用系统能够平滑过渡到安全终态。
❑可继承的默认安全。在多层系统架构下，底层架构的安全配置通常可被上层架构继承，在云原生安全架构下也是如此。在夯实基础设施层安全配置的同时可抽象出与上层对应的安全能力，进一步加固容器应用侧安全，实现系统的纵深防御。
❑默认安全配置应当能阻止通用的漏洞利用。默认安全配置应当能帮助系统抵御常见的安全攻击和漏洞利用。通过在软件供应链管道中集成自动化的配置校验和安全审核，比如强制应用程序以非root身份启动或启用seccomp配置约束应用运行时对系统调用的使用，可以在应用发布前帮助发现并修复程序中隐藏的远程代码执行（RCE）、文件目录遍历、凭证泄露和提权等通用的漏洞利用路径。
❑针对特例提供可配置的安全白名单选项。通常来说，默认安全配置中过于严格的安全约束可能导致和应用层业务需求的冲突。此时应针对特例提供直观的白名单配置，仅开放业务依赖的最小特权，同时结合策略引擎进行自动化控制和审计。
❑明确系统中的安全限制。任何系统都不可能做到百分之百的安全，但是这些安全限制需要在系统中被明确声明并记录在设计流程中，比如为了Kubernetes系统组件的正常运行，需要在集群节点上默认绑定一些云服务商资源的访问权限，在明确告知终端用户配置原因和可能引发安全风险的应用场景之外，还需要不断寻求替代和安全收敛方案。
2.权限最小化
众所周知，权限最小化原则是企业安全运维中最基本也是最重要的准则之一。在传统应用架构下，系统的权限管理员需要基于权限最小化原则对内部人员授权。在云原生架构下，授权管理不止针对企业中的账号系统，同时需要考虑松耦合微服务架构下众多服务身份的授权。这就要求系统权限管理员在理解业务应用目的和使用场景的前提下，严格遵循权限最小化原则在服务维度授权。
3.安全左移、防护右移
云原生敏捷、不可变基础设施等特性大大提高了企业应用开发迭代的效率，也很大程度上改变了企业软件从设计、开发、编译打包、测试、分发到部署的发布流程，而这样的流水线可以称为软件供应链。在传统软件开发流程中，安全审核只有在应用开发完成即将上线发布前才会被强制介入，而这样的审核要么需要安全管理人员对应用全局有完整的掌控，要么只是流于表面的例行检查，无法有效提升软件的安全性，同时也不再适应云原生时代敏捷、高效的应用迭代速率。
为了解决安全防护与软件开发流程日益严重的脱节问题，安全左移的理念应运而生。相较于传统软件开发模式下安全流程的介入方式，安全左移更强调在供应链流程的早期阶段通过自动化的手段发现并解决安全问题，并且这样的安全措施应当能够无缝嵌入供应链的各个环节。安全左移不仅能够有效降低软件自身漏洞而导致的应用风险，而且能够有效降低企业的开发运维成本。在Paloalto《2022年云原生安全报告》中可以看到，将安全左移实践到自身供应链环节的企业在安全态势评级中得到优秀等级的概率是其他企业的9倍。
随着安全左移理念的发展，企业研发运维DevOps流程也随之扩展为DevSecOps。DevSecOps作为云原生时代下的安全开发实践模式，并不仅仅局限于云原生安全，在整个企业应用运维领域都是一个热门的概念，也是安全左移理念的最佳实践。那么，企业应当如何构建自己的DevSecOps流程呢？首先至少应当具备如下组件：
❑完整的自动化CI/CD流水线，以及满足企业应用构建、测试、打包分发和部署上线的基础设施层资源。
❑SDLC（软件开发生命周期）软件，包括IDE等构建工具以及静态/动态应用安全测试和软件成分分析等自动化测试工具。
❑仓库，包括应用源代码仓库和应用镜像仓库。
❑可观测监控工具，集成日志审计、自动化监控告警和自定义监控指标配置等能力的可视化运维管理平台。
而完成DevSecOps转型的企业需要具备如下条件：
❑理念上的转变。在DevSecOps体系中，安全应当是企业内部团队共同的目标，而不应只是安全团队自身的职责；企业开发、运维和安全团队应当协同起来，设定统一的目标并共担责任，同时定义团队之间的交流方式，以有效提升业务迭代效率。
❑标准化的供应链平台。企业需要构建一个标准的自动化供应链平台，DevSecOps的实践依赖企业内部深层次的协同，而不同的工具和实践流程会阻碍跨部门协作的高效性和生产力。标准化的平台能够简化部门之间沟通和学习的成本，让供应链流程更加透明、高效。
❑实现供应链安全自动化。在应用制品的供应链生命周期中应尽早地以自动化方式嵌入安全，同时以自动化方式扫描、发现并治理常见的软件CVE漏洞。通过引入自动化的安全扫描和巡检机制，团队可以在早期扼杀风险，同时整体提升安全意识。
❑充分利用云原生带来的技术红利。企业在DevSecOps的落地实践中可以充分利用云原生技术，包括不可变基础设施和声明式的策略治理能力。同时，部署成熟的安全第三方产品也可以帮助企业快速构建DevSecOps能力。
❑构建供应链SBOM（Software Bill Of Materials，软件物料清单）。SBOM是描述供应链制品中软件包依赖树的一组元数据，包括供应商、版本号和组件名称等关键信息。SBOM可以帮助企业跟踪软件开发生命周期中开源组件之间的依赖关系，增强开源代码的可视性和透明度。企业可以将SBOM集成到自身的DevSecOps流程管道中，为所有软件制品自动生成SBOM，同时在关键节点自动化验证SBOM并使用SBOM数据持续评估安全和合规风险。据Gartner预测，到2025年，超过60%的采购或自建关键基础设施软件的企业将在实践中授权并落地SBOM。可以预见，SBOM将在未来的供应链安全中扮演重要角色。
企业在DevSecOps的落地实践中可以充分利用云原生技术，同时结合云服务商的安全产品能力及部署成熟的安全第三方产品，快速构建DevSecOps能力。
企业应用的安全性需要贯穿应用程序的整个生命周期，如图1-7所示。开发阶段是整个应用生命周期的第一阶段，其结果是创建用于部署和配置应用的云原生模板、容器镜像、应用二进制等云原生制品，这些制品正是运行时被攻击利用的主要源头，因此这个阶段针对不同制品的安全扫描就显得格外重要。
图1-7 云原生应用生命周期安全
构建阶段包括基于CI/CD自动化流水线的各种系统测试，尤其针对开源软件，需要建立明确的漏洞风险分级卡点机制，同时加入自动化的加签机制以支持制品的可信校验。
部署阶段负责进行一系列的“飞行前”检查，以确保将要部署到运行环境中的应用程序符合整个企业的安全和合规规范。
运行时阶段的安全包括计算、存储和访问控制三个关键领域的安全能力。运行时环境的安全性取决于前几个阶段安全实践的有效性，同时需要企业在配置管理、身份和访问控制及威胁检测方向上基于安全原则实现高效的自动化监控和管理能力，并且通过全局的安全资产管理和态势感知能力不断发现风险并反馈到生产开发及供应链的各个环节中。
最后，企业应用安全需要防患于未然，在后续章节中我们会围绕eBPF技术重点介绍如何构建云原生应用的主动免疫、精确审计和风险阻断能力，从而帮助企业安全运维人员从容应对突发的攻击事件，并在规划的指导下做出快速的决策和响应。
4.零信任
零信任安全最早是由Forrester首席分析师John Kindervag在2010年提出的，其核心思想是“Never Trust，Always Verify”。在零信任安全模型中，只要系统处于网络中，默认情况下任何用户都不可信，任何时刻、任何环境下设备和服务的身份权限都需要被持续验证。安全是建立在信任链之上的，如果信任链被打破，那么对资源的访问权限应该被自动取消。直到2020年8月，美国国家标准与技术研究院（NIST）正式发布了“Zero Trust Architecture”，对零信任架构进行了深入的诠释。近两年，在信通院等机构的领导下，我国对零信任理论框架的研究和推广也进入了飞速发展的阶段。可以说经历了十年的演变，零信任已经发展成为新的安全架构。
当然，零信任的发展不应仅停留在理论体系上，也不应仅是企业办公网接入层面的零信任，还应包含企业生产内部设备及应用侧的零信任。目前在各大云服务商落地的零信任产品中，比较知名的包括谷歌的BeyondCorp和ALTS，以及微软发布的Zero Trust零信任框架等。
在云原生时代，企业IT架构已经从传统的单机房模式进化为多云、混合云模式，传统机房架构下的安全信任域在如今的云原生IT架构下已不复存在，而构建在主机之上的容器应用层在结合Kubernetes的编排调度能力后，针对主机的传统安全防护能力也不足以保护云原生企业应用。同时，在应用加速微服务化转型的当下，授权管理的对象已不再局限于终端用户，如何保证微服务之间相互访问的身份管理和权限控制成为新的课题。在零信任下，安全架构从“网络中心化”走向“身份中心化”，其关键是以身份为中心进行访问控制。
零信任在本质上是对企业重要数据或权限的保护，数据加密是传统意义上的保护方式，但在云原生时代，这并不是一个完整的安全方案，需要结合零信任概念，在数据落盘、通信、运算和使用等全流程加密的基础上提供细粒度的身份和权限校验。在实践中需要包含下列要素：
❑信任链。构建大型企业IT系统的信任需要从最基本的信任根开始，通过一系列标准化流程建立一个完整的信任链。其中针对不同的请求主体需要建立对应的信任根，比如：针对人员身份的信任根可以使用MFA（多因子认证）；针对云上主机可以使用芯片厂商提供的安全芯片，基于机密计算技术的不可篡改性实现硬件级别的信任根；针对软件服务，可通过可信构建及对源代码和应用镜像的完整性校验建立信任根。
❑身份。零信任架构下一切请求主体都应当具有身份，而所有访问链路都应该包含足够的请求上下文信息，比如请求者、授权者、访问目的、方式和时间地点等元数据信息，以便在访问控制策略中使用这些信息建立信任关系。
❑持续验证。零信任的理念并不是打破信任，而是强调没有传统意义上绝对信任的假设。我们需要在软件供应链和应用生命周期的各个环节持续进行访问控制，以确保主体的持续可信和动态监测，防止信任滥用。
图1-8为零信任理论体系下的典型架构，架构中各模块的具体功能如下：
图1-8 零信任典型架构
❑信任评估引擎。作为策略决策依赖的数据源，持续提供主体信任等级评估、资源安全等级评估及环境评估等数据。
❑访问控制引擎。基于权限最小化原则，以请求为单元，对访问请求基于上下文、信任等级和安全策略进行动态的权限判定。
❑访问代理。可通过多种形式拦截访问请求，发起对请求主体的身份认证和权限判定。
❑身份安全管理平台。可以是云服务商提供的访问控制系统或企业内部的身份管理平台，以及符合标准规范的4A（认证、账号、授权、审计）等系统。
在实践中要注意对访问主体和客体模型与接口的抽象定义，如何能够在描述清晰、直观且易用的基础上实现针对主体和客体的细粒度访问控制是方案落地的关键点。在云原生领域，如服务网格和Kubernetes原生的网络策略模型都是已经被广泛应用的零信任安全方案。
云原生安全设计需要贯穿应用系统的整个生命周期，通过威胁建模以及基于安全准则的系统安全设计和方案实施，可以在很大程度上帮助应用在事前抵御攻击，同时在事件发生时最小化爆炸半径，避免风险扩大化。在此基础上，还需要构建适合云原生架构特点的安全观测和事件响应能力，实现应用系统安全运营的高效闭环。
区别于传统的应用服务，云原生工作负载在运行时有如下特点：
❑短暂的生命周期，尤其是一些无状态的工作流任务，很可能只有秒级的生命周期。
❑编排引擎会根据节点的实时资源动态调度工作负载，网络IP等应用元数据可能随工作负载的重启而不断变化。
❑由于基础设施的不可变性，对运行时环境的修改在工作负载重启后不会保留。
正因为云原生工作负载自身的特点，在应用运行时，当前大多数云原生安全产品对容器侧用户态进程的检测分析都存在不足。同时针对云原生环境的攻击也日益增多，如何识别应用系统中更多的漏洞和攻击，如何有效防御未知攻击，如何对监测到的攻击事件实现自动拦截、修复等响应动作，同时降低误报、漏报率，是判断云原生环境下安全产品价值的关键指标，而eBPF技术正是提升云原生应用安全观测能力和实现精细化安全事件响应的有力武器。
通过eBPF可以实时获取容器负载中执行的系统调用，并关联映射到容器实例中执行的具体进程上，从而让安全人员可以直观地获取攻击者通过exec等权限进入容器实例中发起攻击的命令，有效帮助针对安全事件的溯源和“止血”。在后续章节中将会详细介绍eBPF技术在云原生安全观测和事件响应方面的应用案例。
基于上一节阐述的云原生安全理论基础，本节将主要介绍国内外在云原生安全领域的典型方法论。
CNCF社区集合了云原生安全领域主要的云服务商代表和领域专家，最早推出了v1版本的《云原生安全白皮书》，奠定了云原生安全的理论基础，也给正在使用云原生技术的云服务商和企业客户提供了重要的理论和实践指导，在业界有着广泛影响力。伴随着云原生技术的飞速发展，2022年CNCF社区推出了v2版本的白皮书，进一步完善和补充了框架内容。
首先，CNCF社区将云原生技术栈分为基础设施、生命周期和云环境三部分，如图1-9所示。这样的云原生技术栈可以适用于不同的云计算服务模式，除了IaaS和PaaS，CaaS（容器即服务，Containers as a Service）和FaaS（函数即服务，Functions as a Service）是云原生环境下典型的应用部署模式，有助于企业充分利用云原生技术红利，简化运维流程，专注应用逻辑，从而有效节约成本。同时，这也对如何在云原生服务模式下保证系统全栈的默认安全提出了新的挑战。
图1-9 CNCF云原生安全架构
云原生应用生命周期管理的4个典型阶段为开发、分发、部署和运行时，下面基于社区建议简述每个阶段针对性的安全工作。
1.开发
开发阶段的安全管理生命周期如图1-10所示。
图1-10 开发阶段的安全管理生命周期
开发阶段是应用生命周期起始的第一阶段，基于安全左移原则，需要在应用开发早期阶段就引入必要的安全需求，并且将安全性设计视为整个应用系统设计的重要环节。企业DevOps团队应该利用安全工具在应用构建阶段自动化卡点发现其中影响安全的高危配置和隐藏漏洞，这些问题在生命周期的早期阶段及时发现可以有效降低企业的运维开发成本，提升应用的整体开发上线效率。一方面，企业安全工具应能够以自动化方式无缝集成在开发人员日常工作的IDE和应用构建工具链中，尽可能多地提供上下文相关的安全信息和直观的修复建议；另一方面，企业应用组件开发应基于API驱动，同时采用金丝雀或蓝绿部署模式，以便进一步提升安全测试的自动化水平。
威胁建模是帮助识别应用风险和核心热点代码的有效手段，企业安全运维和测试人员应针对关键业务核心代码构建系统性测试方案，包括对应用程序代码的静态和动态测试、交互性安全测试、渗透测试及部署后对系统的实时冒烟测试。同时，测试人员应当和开发团队协同集成，只有充分了解了开发、构建环境，才能快速执行内部测试流程。另外，应用代码上线前的审核机制也是提升应用安全性的必要措施。
2.分发
分发阶段的安全管理生命周期如图1-11所示。
图1-11 分发阶段的安全管理生命周期
在云原生应用环境中，应用制品通常是以镜像格式进行规范化打包分发的。在镜像构建的CI流程中，首先应该通过权限控制等手段保证构建服务器的安全隔离性，在此基础上可以集成签名和基于策略的验签环节，同时及时更新安全补丁，保证构建环境的安全、稳定。
镜像的安全扫描是整个软件生命周期中保护容器应用程序的重要环节。通过在供应链流程中集成自动化的镜像扫描，可以帮助开发运维人员了解镜像制品中的漏洞信息，也可以及时发现在开发过程引入的一些第三方依赖包中隐藏的安全漏洞或恶意程序。除了镜像的漏洞扫描，还需要在部署之前通过自动化手段对应用模板的安全配置和资源限制等进行扫描，减少不必要的应用特权配置，避免可能危及系统的安全上下文和系统调用设置。
对于存放制品的仓库，首先需要配置严格的认证、鉴权模型，以保证访问控制的安全性。然后针对供应链流水线的不同阶段创建对应的独立仓库，保证各阶段使用独立类型的测试流程，另外建议团队间使用独立的私有仓库，以保证团队内镜像的来源可信。在镜像的打包构建流程中，需要基于最佳安全实践实施安全加固。对于通用的云原生OCI镜像制品，可以基于SBOM等通用规范进行制品签名，以便于后续制品传播流程中的完整性校验。
3.部署
部署阶段的安全管理生命周期如图1-12所示。
在应用正式部署前，应基于策略模型完成一系列部署前的安全检查，包括镜像签名和完整性校验、部署镜像运行时安全策略（确保满足启动要求的镜像没有高危漏洞或恶意软件等）、部署容器运行时安全策略、主机漏洞和合规性校验及工作负载的网络安全策略校验等，通过一系列的策略治理可以确保应用在运行时的安全合规。
图1-12 部署阶段的安全管理生命周期
部署基于指标的可观测性实践是云原生应用不可缺少的，可以帮助企业安全运维人员及时洞悉系统安全水平，及时通知相关业务负责人处理安全突发事件，及时采取必要的止血措施，同时能够实现对安全事件的审计和溯源。
4.运行时
运行时阶段的安全管理生命周期如图1-13所示。
应用的运行时阶段包含计算、存储和访问控制三个关键领域。在上述供应链开发、版本分发和部署阶段的安全措施是保证应用在运行时安全的先决条件，在此基础上，需要分别在计算、存储和访问控制领域实施必要的安全防护手段。
（1）计算
计算是云原生的核心，也是一个高度复杂和动态演化的存在。考虑到多数情况下容器应用共享运行在同一个主机内核上，我们应该选择针对容器优化剪裁的主机OS基础镜像，这有助于在内核层面减小攻击面。另外，针对OS基础镜像的CVE漏洞时有发生，关系到上层容器应用的安全和稳定，针对OS漏洞的安全扫描和及时修复也是安全运维的必要操作。
图1-13 运行时阶段的安全管理生命周期
随着云原生应用的发展和普及，在金融机构、政府等对数据隐私安全有强诉求的应用背景下，除了使用发展较早的可信平台模块（TPM）或vTPM作为应用底层硬件信任的基础外，也可结合云原生应用将信任链扩展到操作系统内核及其相关组件，以实现应用从底层启动到系统OS镜像、容器运行时到上层应用镜像的完整加密验证链。与此同时，随着机密计算技术的发展，企业可选择部署基于可信执行环境（Trusted Exection Environment，TEE）的机密计算集群，它可以在应用逻辑加载使用数据的计算流程中实现对敏感数据安全性、完整性和机密性的保护。机密计算对隐私数据的运算都被隔离在封闭的TEE中，整个应用系统中除了运行程序的CPU组件外，像系统内核、操作系统、云服务商均无法接触到数据内容。在此基础上，企业还可以结合使用安全沙箱完成应用数据在节点OS内核层面的隔离，以有效防范容器逃逸风险，构建一个从应用数据加载、运算、使用到运行时的全流程隔离环境。
编排层是云原生应用生命周期管理的核心系统，其安全直接影响应用系统的整体安全性和运行时的持续安全性。Kubernetes作为云原生应用编排引擎的事实标准，近年来针对其公开披露的CVE漏洞层出不穷，攻击者可以利用集群控制面和数据面核心组件的漏洞，通过如目录遍历（Directory Traversal）、条件竞争（TOCTTOU）或伪造请求等特定手段完成提权并成功逃逸容器，进而发起对主机侧甚至整个集群和云账号维度的横向攻击。因此，对于集群编排层控制面和数据面核心组件，集群安全运维人员应当遵循如CIS Kubernetes等安全标准基线完成组件配置的安全加固，同时严格遵守权限最小化等安全准则授权，防止管理权限扩散。同时，企业可以结合云服务商提供的安全特性实施如下编排层安全措施：
❑安全策略治理。通过实施安全策略可以在应用部署时有效审计不符合安全约束的带有特权配置的不规范部署实例，在安全等级较高的应用场景下，可开启对不安全应用部署的强制拦截。
❑审计日志。完备的审计日志是识别和追溯系统入侵、权限滥用、配置不当的最直接和最成熟的方法之一。基于审计日志的分析、关联检索和告警是企业安全团队针对攻击事件最直接的处理手段。安全人员应结合云原生应用特性，针对API审计事件的身份标识、API请求对象模型和操作等关键特性检索关键事件，并通过可视化大盘等方式过滤信息。为了防止攻击者逃逸到主机侧通过删除日志等方式掩盖攻击路径，企业应用应当结合云服务商的日志服务第一时间采集同步日志信息，并对日志的访问权限实施严格的访问控制。
❑证书管理。对于没有将控制面托管运行在云服务商的企业集群，集群CA证书、控制面核心组件证书及相关密钥凭证的生命周期管理也是企业安全运维团队需要关心的核心资产。其中，CA私钥是需要严格保护的敏感信息，对于有泄露风险的CA或组件证书要及时轮转，同时对证书过期时间进行日常监控告警也是保证系统稳定性的必要措施。
❑Secrets加密。如Kubernetes这样的编排引擎针对应用中的敏感信息（如数据库密码、应用证书、认证token等）提供了Secrets模型，便于在应用负载中加载和使用，而敏感信息通常是以明文形式编码使用并落盘存储的，仅通过基本的访问控制策略实现逻辑上的读写隔离。因此，像Secrets这样的独立模型仅可以作为应用处理敏感信息的载体和桥梁，并不能保证企业应用关键信息的安全性，那么应用开发者如何在不破坏密钥可加载和使用的前提下保护其读写和传输的安全性？应避免将密钥以硬编码形式出现在软件生命周期流程中，推荐使用外部的密钥管理系统进行密钥的生命周期管理，同时结合云原生密钥工具在应用运行时完成指定密钥的自动化注入和轮转，以有效地避免硬编码的出现。另外，基于云上的安全零信任原则，Secrets的落盘加密也是推荐使用的安全特性，而Kubernetes也提供了相关的加解密框架，以信封加密的方式高效实现Secrets密文的自动化加解密，保护应用密文在云服务商托管侧的读写安全性。
❑运行时安全和监测。在应用运行时对容器内进程、文件系统和网络的监控与安全防护是不可缺少的，另外一些关键的系统调用和不必要放开的网络访问是攻击者利用CVE进行攻击的重要跳板，在传统方式下对系统调用及容器内东西向网络流量的监控和拦截需要相当的内核领域知识储备并结合复杂的策略配置，而eBPF技术的出现帮助开发者有效屏蔽了内核复杂性，使开发者能够以可编程的方式控制内核行为，这就给安全运维人员提供了在应用运行时灵活监控与拦截关键系统调用和恶意流量的切入点，这也是本书后续将重点关注的内容。另外，在一些对安全合规等级有严格要求及需要保护应用敏感数据的场景，使用安全沙箱容器实现应用内核维度的隔离及使用机密计算对应用的核心数据进行运行时加密，都是提升运行时安全的有效手段。
❑制品安全。云原生制品安全在之前的供应链环节已多次强调其重要性，应通过策略控制生产环境，且只部署经过安全认证和签名校验的镜像与模板等制品源文件，同时要能让企业安全运维人员查看制品出处，做到审计溯源。
❑微服务和服务网格。微服务是云原生时代典型的应用部署架构，随着微服务暴露的端口和API数量激增，整个应用系统的安全稳定性变得无法控制。零信任安全针对微服务架构的特点，通过引入以身份为中心的服务东西向认证、鉴权访问控制去重构传统应用架构下的信任基础。服务网格的不断演进也为微服务之间的交互提供了流量控制、弹性和负载均衡及可观测和安全等特性，同时给零信任在微服务架构下的实施提供了直接方案，有助于缩小应用系统攻击面。
❑Serverless和函数安全。由于Serverless架构和函数服务自身架构的特点，平台底层架构需要在多租户场景下保证租户之间的安全隔离，同时避免因CVE漏洞导致的越权风险。对于上层输入函数，需要确保其供应链安全，对输入函数进行有效的过滤和校验，防止SQL注入等风险；同时通过网络策略等形式限制函数出网请求，防止其对恶意C&C服务器的访问。
（2）存储
云原生的弹性敏捷、可扩展和可迁移在对存储密度、速度等方面有新要求的同时，也对云存储的安全、稳定、可观测性提出了更多的诉求。云原生存储涵盖了一系列技术栈，由于不是本书重点，这里只简单列举一些与安全相关的内容。
1）存储栈。存储解决方案通常是多层架构的复杂系统，架构中的不同模块定义了数据应如何被存储、检索、保护，以及如何与应用侧、编排系统、操作系统交互。任意模块的安全稳定都决定着整个存储系统的安全性。企业运维人员需要保护系统拓扑结构中的每一环节，而不是仅仅在数据访问层实施保护。
❑编排。云原生存储是面向应用的声明式应用层存储，通过编排系统为开发者提供了文件系统（如挂载绑定）、存储管理器及基于编排策略的用户或组级别的权限管理能力。运维管理人员可以利用策略治理能力限制容器运行时使用root权限，同时配置权限最小化的用户和组。基于零信任、最小化权限原则及严格实施的访问控制策略是保护云原生存储架构安全的关键。
❑系统拓扑和数据保护。理解整个应用系统的存储拓扑架构是安全防护的前提。常见的拓扑包括所有计算节点访问中央式的存储服务、在多节点上部署分布式存储，以及将应用负载和存储负载整合在同一节点的超融合模式等。针对不同的系统拓扑架构，需要有对应的分层安全机制保护存储数据及分布式存储之间传输的数据。存储系统中的一个关键能力是在保护系统中持久化数据的前提下面向被授权的用户提供权限范围内的数据，其中包括奇偶校验、镜像、纠删码和创建副本等通用技术。接下来是针对数据完整性的校验，包括对块存储、对象存储或文件存储增加哈希及校验和，在保护数据的同时防止数据被恶意篡改。
❑缓存与数据服务。缓存在应用系统中处处可见，在有效提升存储系统性能的同时，需要严格控制缓存层的访问控制安全策略，防止攻击者通过缓存层获取后端数据。
❑数据服务。存储系统通常会实现一些数据服务，通过提供额外的功能来补充核心存储功能，这些功能可以在堆栈的不同层实现，可能包括创建副本和快照（数据的时间点副本）。这些服务通常用于对数据副本进行远程移动，同时必须确保对远程数据使用相同的访问控制和安全策略。
❑物理层或非易失性层。云原生存储并不局限于狭义的云原生虚拟架构，而是重用了云存储在底层基础设施中的红利，也包括虚拟和物理存储能力。应用中的存储系统最终会将数据持久化在某种非易失性的物理介质上。固态硬盘等现代物理存储通常支持自身加密等安全能力，同时在数据设备离开安全域时一定不要忘记安全擦除业务数据。
2）存储加密。存储加密是保证数据安全的核心手段，通常我们说的数据加密包括数据的传输加密和落盘加密。在传输阶段，通常需要使用客户端和服务端双向TLS加密保证传输加密；在数据落盘时，需要结合密钥管理系统（云上或安全等级更高的本地专有HSM），基于标准的对称加密等算法进行数据的保护。考虑到加密对系统性能的影响，需要结合数据的具体逻辑和合规要求等因素设计数据加密的隔离维度，以及是否使用缓存、信封加密等手段提升性能。
3）存储卷保护。对存储卷的保护最重要的是保证只有授权范围内的工作负载容器才可以对其访问，基本且必要的安全措施是定义命名空间维度的信任边界，在此基础上通过安全策略治理等手段防止容器对节点上敏感路径的挂载，以及限制只有合适的节点能够访问目标卷。同时，需要严格限制特权容器的部署，因为特权容器在被攻击者利用后可以使用更多的系统能力进行逃逸，从而挂载节点上的关键数据信息。
（3）访问控制
1）身份和访问控制。以身份为核心的访问控制系统是云原生应用在零信任原则下的安全基石。针对云原生弹性、微服务架构等特性，鉴权方案需要在设计上遵循最小粒度的访问控制原则。由于多云、混合云架构已经在企业中日渐普及，基于特定云服务商的访问控制解决方案已经不能满足多云环境下的分布式应用的认证、鉴权需求，基于通用标准的OIDC（Open ID Connect）或SAML（Security Assertion Markup Language）2.0协议的联合身份体系将是未来被广泛应用的标准方案。
在微服务架构下，应用系统服务间的所有东西向请求都需要配置双向的TLS认证，同时利用通用的鉴权模块配置服务维度的授权，在特殊场景下可以通过配置七层策略达到更细粒度的访问控制。在云原生应用生命周期被大幅缩短的前提下，需要通过统一的身份凭证系统下发和管理服务依赖的临时密钥，同时配置相应的吊销机制。在零信任的前提下，系统内部所有的人机交互和机机交互都必须经过认证、鉴权、审计。
2）密钥和凭证管理。完备的密钥管理方案对于企业应用的安全、稳定至关重要。在企业应用系统开发部署的供应链流程中，任何一个环节对敏感信息的硬编码都有可能导致泄露风险，通过使用云上KMS服务，可以在应用开发、测试、构建等生命周期流程中使用统一的方式进行密钥读写，避免硬编码问题的出现。同时，KMS服务支持自动化的密钥轮转能力，进一步降低了敏感信息泄露和传播的风险，对数据安全等级有较高要求的企业应尽可能使用硬件安全模块（HSM）对密钥进行物理隔离，从而实现更安全的保护。
如何在工作负载中安全地使用密钥也是企业开发运维中需要特别注意的问题。从指定的文件系统路径或环境变量中读取是工作负载中消费密钥的基本方式，那么如何将HSM或KMS服务中的密钥信息自动化注入应用容器内的指定路径下呢？像Kubernetes这样的编排引擎针对敏感信息实现了非持久化的自动化注入机制，用于将存储在外部密钥管理系统中的敏感信息以存储卷的形式动态挂载到应用容器内，同时支持密钥的自动化轮转机制，避免了敏感信息以Secrets等模型实例的形式持久化保存在系统中，防止攻击者通过审计日志或恶意提权导致的信息泄露。
除此之外，实施落盘加密和使用基于底层硬件加密技术的机密计算容器也是提升密钥与凭证安全性的有效措施。特别是在如金融支付、隐私认证或涉及知识产权的核心数据链路，除了保证核心敏感信息在读写和传输过程中的安全性外，还需要保证机密信息在节点内存运算和存储过程中的安全可信，在此场景下推荐使用机密计算技术，以保证敏感信息在代码使用过程中的完整性，实现数据全生命周期的安全可信。
3）服务可用性。保持业务应用服务的稳定、可用是企业安全运维的基本目标。在云原生应用面临的网络攻击中，拒绝服务攻击（DoS）和分布式拒绝服务攻击（DDoS）是最为常见的攻击形式。攻击者试图通过大量恶意冗余流量来淹没企业应用服务或上游网络的正常业务请求流量，使系统网络过载，从而达到服务不可用的攻击目标。
通过有效的访问控制手段来限制或减少应用服务的攻击面是针对此类攻击的基本防御措施，比如从应用设计上收敛涉及对外流量的组件，同时将计算资源配置在负载均衡之后，并通过配置统一的访问控制规则和Web应用防火墙来控制能到达应用的流量。除此之外，基于eBPF技术也能够从系统底层识别攻击流量，并在恶意流量进入内核网络堆栈处理之前完成丢弃处理，从而实现对拒绝服务攻击的高效防御。
Gartner在2021年8月首次发布了《云原生应用保护平台创新洞察》报告，该报告面向云原生应用，旨在通过一系列安全合规集成方案完整地阐述云原生应用从开发到运行时全生命周期的安全模型框架。
1.模型框架和双向反馈能力
在云原生架构下，企业应用通常是基于容器编排引擎或Serverless化的无服务器PaaS层构建的，同时在应用侧又依赖主机侧、云服务商和企业内部数据中心等多方向的网络请求。为了理解云原生应用安全风险并进一步构建完整的安全防护方案，企业安全运维人员需要先进的分析方法，覆盖对应用侧风险、开源组件风险、云基础设施风险和应用运行时风险的完整感知。在企业应用云原生化的同时，企业内部安全架构的重点也相应地从对基础设施的安全加固转向对上层应用负载侧的防护。在这个转型过程中，企业安全生产和运维面临着如下风险：
❑企业开发和安全团队缺乏必要的技能。Gartner的一次调查显示，在企业开发运维流程管道中实践DevSecOps时，评分最高的挑战就是内部缺乏必要的安全知识。
❑企业内部组织架构不成熟，尤其是在应用初期阶段，功能迭代的压力会导致安全手段实施的滞后。
❑企业现有的传统安全防护方案（如CWPP、WAF等第三方安全平台工具）难以整合到云原生当下的DevOps流程中。
❑开发和安全团队各自为政。开发团队不希望接入侵入式的安全卡点流程或者拒绝使用一些误报率高的低效安全工具；而安全团队缺乏对应用全局的了解，使得很难完成对应用整体安全架构的全局治理。
❑企业负责安全防护投入与采购的人员和实际负责应用生命周期管理的团队往往来自不同部门，很容易因为不明确的边界导致企业在安全上的投入无法对症下药。
❑多数云安全态势管理（CSPM）平台缺乏企业所需的基础设施即代码（IaC）的扫描能力，无法实现与企业内部开发管道的集成。
❑安全预算分散在企业内部不同的角色人员之间，对于开发运维管道流程中的安全能力而言，多数时候被集成在IDE工具或代码仓库中，也是多数开发人员能够直接接触到的安全特性，这部分安全能力由于自身重合性导致开发运维人员只会选择使用其熟悉平台内置的安全工具，而企业也缺乏对供应链安全的整体投入。
❑缺少对Kubernetes自身安全配置的扫描和加固。
以上风险很大程度上来自企业内部安全防护手段和观念发展的滞后，以及开发运维团队和安全部门之间的边界问题。为此，Gartner与其他主流云服务商和云安全厂商在已有的CSPM、云基础设施授权管理（CIEM）和CWPP等传统主流云平台安全模型的基础上，提出了云原生应用保护平台（Cloud Native Application Protection Platform，CNAPP）框架，针对云原生应用从开发到运行时的全生命周期流程，为企业安全团队和DevSecOps架构师提供完整视角的应用风险可见性和相应的解决方案，包括应用依赖的开源软件、自定义代码、容器制品、云基础设施配置和运行时防护等维度，如图1-14所示。
图1-14 CNAPP模型中的安全能力
除此之外，相较于传统模型，CNAPP更加强调通过如下原则进一步提升企业应用安全水平：
❑更好地适配云原生应用高速迭代的敏捷特性，通过自动化手段减少错误配置和管理。
❑减少参与供应链CI/CD管道的工具数量。
❑降低云原生应用安全合规实施的复杂性和成本。
❑强调企业内部开发、运维和安全部门的协同一致：对于开发人员，需要允许安全扫描等工具无缝集成到其开发管道和平台中；对于安全人员，尽可能左移安全措施，在强调供应链主动发现并修复安全风险的同时，减少对运行时保护的依赖。
❑帮助企业安全部门深入了解云原生下的典型攻击路径，包括身份、权限、网络和基础设施配置等多维度的溯源与分析。
研发和运维侧的双向反馈飞轮是CNAPP模型中的核心机制，可以帮助加强企业安全可视性和对风险的洞察力，从整体上改善企业安全态势，如图1-15所示。
从研发侧反馈到生产运维阶段，可通过如下安全措施实现预期状态：
❑通过静态安全扫描和软件成分分析等手段保证制品的安全合规。
❑通过基线分析等手段识别制品的默认行为和预期连接。
❑基于漏洞和恶意代码扫描明确剩余漏洞，采取运行时安全防护措施。
图1-15 CNAPP研发和运维侧的双向反馈飞轮机制
❑基于最小化权限原则授权。
❑通过策略治理等手段保证制品的安全完整性。
在生产运维阶段，可通过如下平台侧安全措施不断反馈研发侧可以加固和修复的安全问题：
❑通过动态安全扫描和交互式监视等安全工具识别应用代码漏洞。
❑基于云原生安全态势感知方案识别安全资产，收敛权限并设置安全策略。
❑基于云原生应用负载安全防护手段发现并阻断运行时安全攻击事件。
❑基于云原生运行时安全监控手段为开发阶段提供应用运行时安全上下文。
❑基于云原生安全巡检工具识别应用高危配置和潜在攻击风险。
2.对企业安全的指导意义
对于企业安全运维管理团队，CNAPP框架强调了以下几点：
❑在企业云原生应用中需要实施完整的安全手段，涵盖从应用开发到生产运行的完整供应链流程。
❑基于安全左移原则，将安全集成到开发人员的工具链中，在代码创建阶段就通过自动化构建管道触发安全测试，以降低后续安全风险和运维成本。
❑不存在无懈可击的完美应用，开发人员应关注风险和威胁等级最高的漏洞，以避免不必要的开发运维成本。
❑全面扫描应用制品和平台配置，并结合运行时安全配置上下文，提前考虑风险处理等级预案。
基于CNAPP理论框架，信通院在2022年云原生产业联盟年会上发布了《云原生应用保护平台（CNAPP）能力要求》，进一步细化了规范要求，同时在云原生制品安全、基础设施安全、运行时安全、双向反馈能力和环境适配能力五大方向上提出了具体的评测标准和分级能力要求，为企业云原生安全建设和评估提供了重要的规范和参考标准。
云原生安全是本书主要关注的eBPF典型应用场景，因此在介绍eBPF技术之前，本章首先介绍了云原生及云原生安全的定义。随着越来越多的企业生产架构开始进行云原生转型，云原生安全成为企业关心的热点问题。为了帮助读者对云原生安全有更全面的了解，我们还介绍了云原生给传统架构下的企业安全带来的新挑战及云原生安全需要解决的主要问题和关键演进。
然后，我们重点介绍了云原生安全中重要的理论基础，以及在理论基础上构建的典型方法论，主要包括CNCF社区针对云原生安全发布的白皮书以及面向云原生应用安全的CNAPP报告，进一步阐述了云原生环境中企业如何构建完善的纵深防御体系。
eBPF作为近年来热门的技术之一，可以在云原生环境中帮助收集应用容器在操作系统内核层面的关键事件操作，同时也可以有效提升地云原生网络安全策略的实施效率及整个容器网络的可观测性，是发展云原生安全运行时事件响应、取证及安全可观测能力必不可少的基础，也是企业构建完整的云原生安全运维体系重要的技术保障。下一章开始，我们将围绕eBPF讲述其技术原理及在云原生安全领域的典型应用。