云原生安全威胁分析与能力建设白皮书-2023.12

云原生安全威胁分析与能力建设白皮书中国联通研究院中国联通网络安全研究院下一代互联网宽带业务应用国家工程研究中心2023

年

11

月1版权声明本报告版权属于中国联合网络通信有限公司研究院，并受法律保护。转载、摘编或利用其他方式使用本报告文字或者观点的，应注明“来源：中国联通研究院”。违反上述声明者，本院将追究其相关法律责任。云原生安全威胁分析与能力建设白皮书目

录一、云原生安全概述91.1

云原生及云原生安全

91.1.1

云原生

101.1.2

云原生安全

121.2

云原生安全发展141.3

云原生安全风险17二、云原生关键技术威胁全景192.1

云原生安全威胁分析192.2

路径

1：镜像攻击

212.2.1

镜像投毒攻击212.2.2

镜像仓库攻击222.2.3

中间人攻击

222.2.4

敏感信息泄露攻击222.2.5

针对镜像不安全配置的攻击

222.3

路径

2：容器攻击

232.3.1

守护进程攻击232.3.2

容器提权和逃逸攻击242.3.3

拒绝服务攻击251云原生安全威胁分析与能力建设白皮书2.3.4

容器网络攻击262.4

路径

3：编排工具攻击262.4.1k8s

组件攻击272.4.2

服务对外暴露攻击272.4.3

业务

pod

攻击

282.4.4

集群环境下的横向攻击292.4.5k8s

管理平台攻击292.4.6

第三方组件攻击292.5

路径

4：微服务攻击

292.5.1API

攻击302.5.2API

网关攻击322.5.3

微服务应用攻击322.6

路径

5：Serverless

攻击332.6.1

事件注入攻击342.6.2

敏感数据泄露攻击342.6.3

身份认证攻击352.6.4

权限滥用攻击352.6.5

拒绝服务攻击362云原生安全威胁分析与能力建设白皮书2.6.6

针对函数供应链的攻击36三、典型攻击场景分析

373.1

镜像投毒攻击373.1.1

攻击场景介绍373.1.2

攻击过程复现383.2

挂载

Docker

Socket

导致容器逃逸攻击383.2.1

攻击场景介绍383.2.2

攻击过程复现393.3k8s

权限提升攻击403.3.1

攻击场景介绍403.3.2

攻击过程复现413.4Istio

认证策略绕过攻击

433.4.1

攻击场景介绍433.4.2

攻击过程复现45四、云原生应用保护能力建设474.1

制品安全能力建设474.1.1

代码安全

484.1.2

镜像安全

493云原生安全威胁分析与能力建设白皮书4.1.3

制品环境安全504.1.4

安全检测

524.2

运行时安全能力建设534.2.1Web

应用和

API

安全544.2.2

云原生运行时安全564.2.3

网络微隔离

584.3

基础设施安全能力建设594.3.1

基础设施即代码安全594.3.2

权限管理

604.3.3

云原生安全态势60五、总结与展望62六、参考文献644云原生安全威胁分析与能力建设白皮书图

目

录图

1

云原生四要素10图

2

云原生四要素的基本含义11图

3

云原生安全框架

13图

4

云原生安全能力体系

16图

5

云原生关键技术威胁全景19图

6

容器镜像安全风险

21图

7

容器运行时安全风险

23图

8

针对

k8s

进行攻击的路径分析

27图

9

针对微服务进行攻击的路径分析

30图

10

针对

Knative

进行攻击的路径分析33图

11

镜像投毒攻击路径分析

37图

12

反弹

shell

攻击结果展示38图

13

容器逃逸结果展示40图

14

k8s

权限提升攻击路径

41图

15

利用

CVE-2018-1002105

窃取高权限凭证42图

16

未授权访问结果45图

17

绕过

Istio

JWT

认证访问结果45图

18

云原生应用保护能力建设架构图47图

19

制品安全能力建设485云原生安全威胁分析与能力建设白皮书图

20

运行时安全能力建设54图

21

基础设施安全能力建设

59表

目

录表

1

云原生安全相关标准

156云原生安全威胁分析与能力建设白皮书前

言在数字化转型的大潮中，云计算作为实现创新和提高运营效率的关键技术，成为了新一代信息技术的核心引擎。随着云计算的飞速发展和广泛应用，以及万千企业数字化转型换挡提速，企业对云计算的使用效能提出新的需求。云原生以其独特的技术特点，很好地契合了云计算发展的本质需求，正在成为驱动云计算质变的技术内核。云原生作为云计算深入发展的产物，已经开始在

5G、人工智能、大数据等各个技术领域得到广泛应用。中国联通研究院一直从事云原生及其安全技术的研究，致力于推动云原生在通信行业落地实践，全面落实好“大安全”主责主业，以实际行动践行“国家队、主力军、排头兵”的责任担当。2022

年，我们在“联通合作伙伴大会”发布了《中国联通云原生安全实践白皮书》，该书系统阐述了云计算所面临的新型安全问题，介绍了云原生安全防护体系，并给出了云原生安全防护体系建设实践。过去一年来，我们持续深耕云原生安全领域，联合多家单位共同编写了《云原生安全威胁分析与能力建设白皮书》。白皮书从攻击者视角介绍了云原生所面临的安全威胁，通过具体的实例展现攻击过程，给出云原生应用保护能力建设思路，以期与行业同仁共同推动云原生安全落地发展。最后，白皮书内容难免有疏漏，敬请读者批评指正。7云原生安全威胁分析与能力建设白皮书编写单位：中国联合网络通信有限公司研究院、联通数字科技有限公司、中国联通福建省分公司、北京神州绿盟科技有限公司、北京小佑网络科技有限公司、中兴通讯股份有限公司专家顾问：叶晓煜、张建荣、徐雷、潘松柏、冯强、张曼君、傅瑜、葛然、张小梅、徐积森、滕开清编写成员：丁攀、郭新海、王戈、刘安、蓝鑫冲、牛金乐、李安坤、王琦、汤旭、雷新、浦明、张小勇、白黎明、左伟震、范璟玮、许秀莉8云原生安全威胁分析与能力建设白皮书一、云原生安全概述近年来，云计算技术一直处于高速发展的过程中，并且随着公有云和私有云的广泛应用，利用云计算作为承载业务运行的基础设施，已经成为了企业的首选。“十四五”时期，中国的信息化进入加快数字发展、建设数字中国的新阶段，在数字化转型的浪潮中，云计算作为新型数字基础设施和新一代信息技术的核心引擎，在推动人工智能、5G、工业互联网、物联网等技术的发展和应用方面发挥着越来越重要的作用。云计算的普遍应用和相关技术发展，使其已经经历了云计算

1.0

虚机时代、云计算

2.0

原生时代，目前正在朝着云计算

3.0

智能时代迈进。因此，在当前云计算

2.0

时代，云原生技术日趋成熟，并因大语言模型的推动助力朝着云计算

3.0

智能时代迈进的背景下，分析云原生安全的发展情况和面临的威胁，并研究云原生安全能力，能够为企业整体的云安全防护体系建立提供帮助，从而保障企业业务和数据更安全的在云上运转。1.1

云原生及云原生安全过去十年，企业数字化转型加速推进，相继经历了服务器、云化到云原生化三个阶段。在云化阶段，云主机是云计算的核心负载之一，云主机安全是云安全的核心；在云原生阶段，容器和无服务器计算成为核心工作负载，容器安全、Serverless

安全、DevSecOps

成为云安全的核心。自开源

Docker

容器和

k8s编排引擎出现以来，云原生生态不断扩大。当前，云原生作为云计算深入发展的产物，已经开始在

5G、人工智能、大数据等各个技术领域得到广泛应用。云原生技术的广泛应用，带来了一系列云原生安全问题，因此，要保障云原生的安全，9云原生安全威胁分析与能力建设白皮书使云原生技术更好的赋能企业数字化发展，需要明确云原生和云原生安全。1.1.1

云原生2015

年，Pivotal

的高级产品经理

Matt

Stine

发表新书《迁移到云原生应用架构》，探讨了云原生应用架构的

5

个主要特征：符合

12

因素应用、面向微服务架构、自服务敏捷架构、基于

API

的协作和抗脆弱性。同一年，Google作为发起方成立

CNCF，指出云原生应该包括容器化封装、自动化管理、面向微服务。到了

2018

年，CNCF

又更新了云原生的定义，把服务网格和声明式API

给加了进来。后来，随着云计算的不断发展，云原生的簇拥者越来越多，这一体系在反复的修正与探索中逐渐成熟。VMware

关于云原生的介绍提出了四个核心要点，包括

DevOps、微服务、容器和持续集成，如图

1、图

2

所示。图

1

云原生四要素10云原生安全威胁分析与能力建设白皮书图

2

云原生四要素的基本含义2020

年，云原生产业联盟发布《云原生发展白皮书》[1]，指出云原生是面向云应用设计的一种思想理念，充分发挥云效能的最佳实践路径，帮助企业构建弹性可靠、松耦合、易管理可观测的应用系统，提升交付效率，降低运维复杂度，代表技术包括不可变基础设施、服务网格、声明式

API

及

Serverless

等。云原生技术架构的典型特征包括：极致的弹性能力，不同于虚拟机分钟级的弹性响应，以容器技术为基础的云原生技术架构可实现秒级甚至毫秒级的弹性响应；服务自治故障自愈能力，基于云原生技术栈构建的平台具有高度自动化的分发调度调谐机制，可实现应用故障的自动摘除与重构，具有极强的自愈能力及随意处置性；大规模可复制能力，可实现跨区域、跨平台甚至跨服务的规模化复制部署。由此可见，云原生作为一种新兴的安全理念，是一种构建和运行应用程序的技术体系和方法论，以

DevOps、持续交付、微服务和容器技术为代表，符合云原生架构的应用程序应该：采用开源堆栈（k8s+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps

支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。11云原生安全威胁分析与能力建设白皮书1.1.2

云原生安全云原生安全作为云原生的伴生技术，旨在解决云原生技术面临的安全问题，其作为一种新兴的安全理念，强调以原生的思维实现云上安全并推动安全与云计算深度融合。我们在

2022

年发布的中国联通云原生安全实践白皮书中[2]，对

比分析了不同的组织和企业对云原生安全理念的理解，其中包括

CNCF

认为云原生安全是一种将安全构建到云原生应用程序中的方法[3]、k8s

提出的云原生

4C安全模型[4]、腾讯所理解的云原生安全指云平台安全原生化和云安全产品原生化[5]，并给出我们对于云原生安全的理解，即云原生安全是云原生理念的延伸，旨在解决云原生技术面临的安全问题。CSA

发布的《云原生安全技术规范》中给出了云原生安全框架[6]，如图

3所示。其中，横轴是开发运营安全的维度，涉及需求设计（Plan）、开发（Dev）、运营（Ops）,细分为需求、设计、编码、测试、集成、交付、防护、检测和响应阶段；而纵轴则是按照云原生系统和技术的层次划分，包括容器基础设施安全、容器编排平台安全、微服务安全、服务网格安全、无服务计算安全五个部分，二维象限中列举安全机制（蓝色标注部分）已经基本覆盖全生命周期的云原生安全能力。此外，DevSecOps

涉及的能力范围几乎覆盖了横轴和纵轴的各个阶段，如图中的紫色部分。最后，云原生安全体系中还包括了一些通用技术能力（黄色部分），这一部分能力主要体现在检测和响应阶段，并会同时覆盖

DevSecOps中运营阶段的能力。12云原生安全威胁分析与能力建设白皮书图

3

云原生安全框架由此可见，云原生安全可以简要归纳为两个方面，一是面向云原生环境的安全，其目标是防护云原生环境中的基础设施、编排系统、微服务、无服务和服务网格等安全。二是具有云原生特征的安全，指具有云原生的弹性敏捷、轻量级、可编排等特性的各类安全机制。在此基础上，未来云原生环境必将与云原生技术的安全互相融合，成为统一的整体，并且将经历如下三个发展阶段：（1）安全赋能于云原生体系，构建云原生的安全能力。当前云原生技术发展迅速，但相应的安全防护匮乏，最基础的镜像安全和安全基线都存在很大的安全风险。因此，应该将现有的安全能力，如隔离、访问控制、入侵检测、应用安全等，应用于云原生环境，构建安全的云原生系统；（2）安全产品具有云原生的新特性，如轻/快/不变的基础设施、弹性服务13云原生安全威胁分析与能力建设白皮书编排、开发运营一体化等。通过软件定义安全架构，构建原生安全架构，从而提供弹性、按需、云原生的安全能力，提高“防护—检测—响应”闭环的效率；（3）在安全设备或平台云原生化后，提供云原生的安全能力，不仅适用于通用云原生、5G、边缘计算等场景，还可以独立部署在大型电商等需要轻量级、高弹性的传统场景，最终成为无处不在的安全。1.2

云原生安全发展云原生在改变了企业上云及构建新一代基础设施的同时，作为一项新兴技术也带来了一系列新的问题，对企业原有的信息安全防护模式提出了新的挑战，例如，微服务、容器运行时的短生命周期、CI/CD

全流程监控缺失、镜像及供应链的复杂性等。另外，云原生技术生态涵盖基础设施到

DevOps

开发多个维度，这打破了原有的信息安全视角。在应对不断出现的针对云原生基础设施、平台及容器的安全威胁过程中，原有的安全体系也产生了变革。主要表现在如下几个方面：

防护对象产生变化安全管理的边界扩展到了容器层面，需要采用新的安全策略和工具来保护容器的安全性，如容器镜像的验证和加密、容器漏洞扫描和运行时监测等。

架构的变化多云及混合云下的应用架构及工作负载更加复杂，需要采用分布式安全策略和技术，如服务间的身份验证和授权、服务网格的加密通信、微服务的监测和异常检测等。

管理模式的变化14云原生安全威胁分析与能力建设白皮书云原生应用的快速迭代和部署频率也对安全治理模式提出了新的要求。传统的安全治理模式通常是基于静态的规则和策略，针对云原生

DevOps

安全治理需要采用持续安全集成和交付的实践，结合自动化的安全测试、漏洞扫描和合规性检查等工具，以确保安全策略和控制的持续有效性。面对这些新的挑战，国内外都开展了云原生安全技术的研究和相关标准规范的制定完善工作，CNCF、CSA

等组织以及行业联盟等纷纷提出云原生安全标准及参考技术规范。同时，主要经济体国家的标准也在制订和完善过程中，使得行业逐步走向规范，推动了产品和解决方案逐步走向成熟。在中国信息通信研究院、云安全联盟和相关企业的共同努力下，云原生的安全标准陆续制定和颁布，当前相关主要的标准如表

1：表

1

云原生安全相关标准序号1标准名称简要内容由云安全产业联盟提出并归口，规定了云原生安全配置基线扫描应具备的基础规范要求。云原生安全配置基线扫描规范要求包括

API

Server

安全配置要求、控制管理器安全配置要求、调度器安全配置要求、工作负载安全配置要求、

etcd

安全配置要求、

kube-proxy

安全配置要求、

kubelet

安全配置要求、

CNI

和网络策略安全配置要求云原生安全配置基线规范网络安全等级保护容器安全要求由中关村信息安全测评联盟团体标准委员会提出并归口，规定了在云环境中采用容器集群技术的等级保护对象要求，包括第一级至第四级的安全要求。23由中国信息通信研究院牵头编写，规定了基于云原生技术的平台架构的能力成熟度评估模型，从服务化能力、资源弹性能力、可观测性、故障自愈能力、自动化能力、无服务器化能力以及安全性等方面对技术架构进行评估。云原生能力成熟度模型

第

1部分：技术架构由中国信息通信研究院牵头编写，规定了基于云原生构建的业务应用的能力成熟度评估模型，从服务架构、服务治理能力、弹性伸缩能力、业务高可用、自动化与智能化、可观测性、开放性、组织架构以及安全性等方面对业务应用进行评估。云原生能力成熟度模型

第

2部分：业务应用415云原生安全威胁分析与能力建设白皮书云原生能力成由中国信息通信研究院牵头编写，规定了基于云原生构建的平台与应用的安熟度模型

第

3

全能力成熟度评估模型，包括基础设施安全域、云原生基础架构安全域、云56部分：架构安全

原生应用安全域、云原生研发运营安全域以及云原生安全运维域五个方面范围由中国信息通信研究院牵头编写，适用于用帮助用云企业评估自身云原生平云原生安全台和应用的

API

安全防护能力水平，定位问题、指导能力建设，适用于规范API

安全治理云服务商、安全企业提供的产品及服务的能力水平。由中国信息通信研究院牵头编写，为了云原生应用保护平台（CNAPP）的云原生应用保框架并对每个功能模块提出了能力要求，内容包含制品管理、基础设施配置护平台7管理、运行时保护、双向反馈机制与环境适配能力，覆盖云原生应用的开发（CNAPP）能运营全流程，适用于指导企业云原生应用运维保护能力建设，规范和测评云力要求原生应用保护产品质量另外，云原生安全相关的技术也在不断完善中，由于云原生安全的核心是要保证云原生应用及数据安全，因此云原生安全技术体系也需要围绕云原生应用的生命周期来构建，相关安全能力包括容器安全、代码及应用安全、平台安全以及基础设施安全在内的四层关键能力，以及多云之间的安全管理和防护能力，部分云原生安全能力如图

4

所示。图

4

云原生安全能力体系云原生安全作为一种新兴的安全理念，不仅要解决云计算普及带来的安全问16云原生安全威胁分析与能力建设白皮书题，更应强调以原生的思维构建云、端一体化安全，推动安全与云计算的深度融合，达到安全左移、持续监控与持续响应的目标。1.3

云原生安全风险云原生技术的应用带来了更多的安全风险，包括容器化基础设施风险、容器编排平台的风险、云原生应用的风险等，这些风险对云网构成越来越严重的威胁。例如企业云、5G

核心网和边缘计算、工业互联网等场景如今都面临着云原生安全风险。在企业云环境方面，容器化基础设施和云原生应用广泛应用。2023

年

9

月，腾讯研究院发布的《2023

年上半年云安全态势报告》显示[7]，在云环境中容器资产占比达到

45.06%，攻击者通过攻击容器，就可以进一步获取宿主机系统权限，威胁宿主机上的其他容器和内网安全。另外，随着各个企业云上业务的快速发展，越来越多的应用开发深度依赖

API

之间的相互调用。根据

2023

上半年的攻击数据显示，攻击者利用

API

Key、敏感文件执行、敏感信息读取等手段发起的攻击次数呈明显上升趋势，占总攻击事件的

1.69%。API

滥用已成为导致企业

Web

应用程序数据泄露的最常见的攻击媒介，通过攻击

API

来达成攻击目的，已成为上半年攻防演练中各攻击队最常用的攻击手段之一。在

5G

核心网和边缘计算方面，容器化的网元和边缘计算平台越来越普遍，5G

网元承载的服务和边缘计算平台都可以在编排平台的支撑下，以微服务的模式提供业务服务。这些基于容器、编排和微服务技术的

5G

核心网网元和边缘计算平台就面临着云原生安全威胁和风险。在工业互联网方面，构建

IT

和

OT

融合的全互联、扁平化、灵活化的工业17云原生安全威胁分析与能力建设白皮书网络体系结构是工业网络发展的必然趋势，工业互联网连接了

IT

和

OT

环境，如果一个恶意的容器应用能横向渗透到

OT，则可能会威胁整个工业互联网体系的安全。18云原生安全威胁分析与能力建设白皮书二、云原生关键技术威胁全景随着云原生技术的广泛应用，容器化基础设施、容器编排平台以及云原生应用等都面临着多种多样的新型安全威胁，这些威胁直接或间接影响着云网环境的整体安全。因此，全面分析云原生关键技术的威胁，形成云原生关键技术的威胁全景图和攻击路径图，能够帮助企业构建更完善的云原生安全防护体系，从而更全面的保障云网环境的安全。2.1

云原生安全威胁分析云原生化的应用主要由两个部分组成，一是支撑应用的云原生计算环境，包括容器、镜像、镜像仓库、网络和编排系统等。二是云原生化的应用本身，主要包括微服务、Serverless。图

5

中攻击路径

1

至攻击路径

5，从攻击者角度展示云原生应用关键技术面临的安全威胁。图

5

云原生关键技术威胁全景路径

1：攻击者通过攻击镜像层，改变云原生应用的不可变基础设施，引导19云原生安全威胁分析与能力建设白皮书受害者使用该镜像创建容器，进而实现入侵容器、宿主机的目的。路径

1

显示针对镜像层可能存在的攻击手段，包括：镜像投毒攻击、镜像仓库攻击、中间人攻击、敏感信息泄露攻击和针对镜像不安全配置的攻击。路径

2：攻击者直接对容器或容器运行时发起攻击，通过利用容器或容器运行时存在的漏洞，实现入侵宿主机的目的。其中低级容器运行时负责创建和运行容器，而高级容器运行时负责容器镜像额传输和管理等，低级容器运行时和高级容器运行时只是强调了容器化的不同方面。路径

2

显示针对容器运行时可能存在的攻击手段，包括：容器运行时攻击、容器提权和逃逸攻击、拒绝服务攻击和容器网络攻击。路径

3：攻击者对编排工具发起攻击，通过利用编排工具存在的漏洞，实现入侵宿主机的目的。路径

3

显示针对编排工具可能存在的攻击手段，包括：攻击

k8s

组件、服务对外暴露攻击、业务

pod

攻击、集群环境下的横向攻击、k8s管理平台攻击和第三方组件攻击路径

4：攻击者针对微服务发起攻击，如通过利用存在安全风险的

API

网关、API

以及微服务应用本身，实现入侵的目的等。路径

4

显示针对微服务可能存在的攻击手段，包括：API

攻击、API

网关攻击和微服务应用攻击。路径

5：针对

Serverless

发起攻击，无服务器架构颠覆性的变化，给应用服务开发商和拥有者带来了全新的安全挑战。路径

5

显示了攻击者利用Serverless

存在的安全风险进行攻击的路径，可能存在的攻击手段包括：事件注入攻击、敏感数据泄露攻击、身份认证攻击、权限滥用攻击、拒绝服务攻击和针对函数供应链的攻击。20云原生安全威胁分析与能力建设白皮书下面我们对威胁全景中攻击路径

1

至路径

5

的具体攻击手段，进行详细的分析。2.2

路径

1：镜像攻击镜像是一个包含应用/服务运行所必需的操作系统和应用文件的集合，用于创建一个或多个容器，容器和镜像之间紧密联系，镜像的安全性将会影响容器安全。图

6

展示了攻击者利用镜像进行攻击的主要方式。图

6

容器镜像安全风险2.2.1

镜像投毒攻击攻击者通过上传恶意镜像到公开仓库或受害者本地仓库，然后将恶意镜像伪装成正常镜像以引导受害者使用该镜像创建容器，从而实现入侵。根据入侵目的的不同，可以分为恶意后门镜像和恶意

EXP

镜像。恶意后门镜像攻击者的目的是为了控制容器，一般是在受害者使用镜像启动容器后，就会向攻击者反弹一个容器的

shell。这种情况下攻击者可能是为了部署挖矿程序或者攻击容器内运行的业务。恶意

EXP

镜像攻击者的目的是利用隐21云原生安全威胁分析与能力建设白皮书藏在其中的

Exploit

进行容器逃逸，然后获得宿主机的控制权。2.2.2

镜像仓库攻击这里指的是攻击受害者本地的镜像仓库，如

Harbor[8]、Docker

Registry[9]等。其中

Harbor

镜像库从发布开始就被爆出权限提升、枚举、SQL

注入、CSRF等多项漏洞。除此之外，如果私有镜像仓库由于配置不当而开启了

2357

端口，将会导致私有仓库暴露在公网中，攻击者可直接访问私有仓库并篡改镜像内容，造成仓库内镜像的安全隐患。2.2.3

中间人攻击如何保证容器镜像从镜像仓库到用户端的完整性也是镜像面临的一个重要安全问题。由于用户以明文形式拉取镜像，如果用户在与镜像仓库交互的过程中遭遇了中间人攻击，导致拉取的镜像在传输过程中被篡改或被冒名发布恶意镜像，会造成镜像仓库和用户双方的安全风险。2.2.4

敏感信息泄露攻击当开发人员使用默认的或在容器镜像中保留硬编码的敏感数据，比如密码、API

密钥、加密密钥、SSH

密钥、令牌等，或者在

Dockerfile

文件中存储了固定密码等敏感信息并对外进行发布，都可能导致数据泄露的风险。攻击者会使用扫描工具，比如

SecretScanner

等，探测镜像中存在的敏感信息，发现容器镜像和文件系统中的敏感数据。2.2.5

针对镜像不安全配置的攻击镜像是容器运行的基础，容器引擎服务通过使用不同的镜像来启动容器。镜像是按层封装好的文件系统和描述镜像的元数据构成的文件系统包，包含应用所22云原生安全威胁分析与能力建设白皮书需要的系统、环境、配置和应用本身。如果镜像配置不当，将会导致运行的容器面临攻击的危险，比如镜像未使用特定用户账号进行配置导致运行时拥有的权限过高，从而引起容器逃逸等安全风险。2.3

路径

2：容器攻击容器提供了独立隔离的环境来打包和运行应用程序，容器的隔离和安全措施使得用户可以在给定主机上同时运行多个容器。通过

Namespace、Cgroup、Capability、内核强访问控制等多种安全机制以及隔离措施，保证容器内应用程序的安全与隔离。图

7

展示了攻击者可能利用的直接对容器进行攻击的方式。图

7

容器运行时安全风险2.3.1

守护进程攻击Docker

Daemon

是

Docker

架构中一个常驻后台的

Docker

守护进程，用于监听

REST

API

请求并相应地执行容器操作，只有信任的用户才能向

DockerDaemon

发起请求。默认情况下，对于

Docker

Daemon

的访问请求未经加密和身份验证，攻击者可能通过伪造请求的方式，来达到欺骗

Docker

Daemon端执行危险的操作。23云原生安全威胁分析与能力建设白皮书除此之外，攻击者可以通过暴露在互联网端且不安全的

Docker

Daemon，获得

Docker

平台的完全控制权，进而再部署“挖矿”或其他恶意容器。由于Docker

Daemon

作为主机上的根进程运行，攻击者还可能获得主机的完全控制权。2.3.2

容器提权和逃逸攻击攻击者通过劫持容器，获得了容器内某种权限下的命令执行能力，然后利用这种命令执行能力，借助一些手段进一步获得该容器所在宿主机上某种权限下的命令执行能力，实现容器逃逸的目的。根据不同的原因，容器逃逸方式包括以下几方面：内核漏洞导致的容器逃逸：容器本身是一种受到各种安全机制约束的进程，因此从攻击角度来看，攻击者通过权限提升达到逃逸的目的，一旦有新的内核漏洞产生，就需要考虑它是否能够用于容器逃逸。危险配置导致的容器逃逸：Docker

容器基于

Linux

内核中的

Capabilities特性划分特权集，以便进程可以只分配“执行特定功能”的特权，例如通过使用privileged

参数获得所有特权集，使用

cap-add

和

cap-drop

参数增减特权集。然而，无论是细粒度权限控制还是其他安全机制，用户都可以通过修改容器环境配置或在运行容器时指定参数来缩小或扩大约束。如果用户为不完全受控的容器提供了某些危险的配置参数，就为攻击者提供了一定程度的逃逸可能性。需要特别强调的是，当用户通过

Privileged

参数运行特权容器时，容器将具备访问宿主机资源的权限，同时可以修改

AppArmor

或

SELinux

的配置。该场景下，攻击者可以通过多种手段实现容器逃逸，例如可以直接在容器内部挂载24云原生安全威胁分析与能力建设白皮书宿主机磁盘，然后通过切换目录实现容器逃逸。危险挂载导致的容器逃逸：为了方便宿主机与容器进行数据交换，用户往往会采用将宿主机目录挂载到容器中，将宿主机上的敏感文件或目录挂载到容器内部

，

将

会

导

致

容

器

逃

逸

风

险

。

例

如

Docker

Socket

套

接

字

文

件（/var/run/docker.sock）、宿主机的

procfs

文件等敏感文件。程序漏洞导致的容器逃逸：参与到容器生态中的服务端、客户端程序自身存在的漏洞都可能导致容器逃逸的风险，例如

CVE-2019-5736

漏洞。2.3.3

拒绝服务攻击由于容器与宿主机共享

CPU、内存、磁盘空间等硬件资源，且

Docker

本身对容器使用的资源并没有默认限制，如果单个容器耗尽宿主机的计算资源或存储资源（例如进程数量、存储空间等），就可能导致宿主机或其他容器的拒绝服务。计算型

DoS

攻击：Fork

Bomb

是一类典型的针对计算资源的拒绝服务攻击手段，其可通过递归方式无限循环调用

fork()系统函数，从而快速创建大量进程。由于宿主机操作系统内核支持的进程总数有限，如果某个容器遭到了

ForkBomb

攻击，那么就有可能存在由于短时间内在该容器内创建过多进程而耗尽宿主机进程资源的情况，宿主机及其他容器就无法再创建新的进程。存储型

DoS

攻击：针对存储资源，虽然

Docker

通过

Mount

命名空间实现了文件系统的隔离，但

CGroups

并没有针对

AUFS

文件系统进行单个容器的存储资源限制，因此采用

AUFS

作为存储驱动具有一定的安全风险。如果宿主机上的某个容器向

AUFS

文件系统中不断地进行写文件操作，则可能会导致宿主25云原生安全威胁分析与能力建设白皮书机存储设备空间不足，无法再满足其自身及其他容器的数据存储需求。2.3.4

容器网络攻击Docker

提供桥接网络、MacVLAN、Overlay

等多种组网模式，可分别实现同一宿主机内容器互联、跨宿主机容器互联、容器集群网络等功能。由于容器间的网络缺乏安全管理机制，无法对同一宿主机内各容器之间的网络访问权限进行限制。因此，无法避免容器间互相攻击的安全风险。容器网络所面临的攻击主要包括容器网络内部攻击和容器网络外部攻击。容器网络内部，由于网络流量不通过物理网卡而在宿主机内部的容器通信，存在容器虚拟网络间的

DoS

攻击风险。容器网络外部，由于宿主机上的所有容器共享物理网卡资源，若外部攻击者向某一个目标容器发送大量数据包进行DDoS

攻击，将可能占满宿主机的网络带宽资源，造成宿主机和其他容器的拒绝服务。2.4

路径

3：编排工具攻击编排工具的工作依赖于容器及容器镜像技术，所以用户在使用编排工具时，同样会面临容器及容器镜像的安全风险。在针对编排工具的攻击一节，我们重点介绍编排工具本身存在的安全风险。目前，常见的开源编排工具包括

k8s[10]、OpenShift[11]等，其中

k8s

在功能性、通用性以及扩展性方便表现良好，同时具有较强的社区支持，使其得到广泛的应用。图

8

以

k8s

为例展示了编排工具的架构，以及攻击者可能对编排工具进行攻击的方式26云原生安全威胁分析与能力建设白皮书图

8

针对

k8s

进行攻击的路径分析2.4.1k8s

组件攻击攻击点

1

至攻击点

4，罗列了

k8s

各组件的不安全配置可能带来的安全风险，即

API

Server

未授权访问、etcd

未授权访问、kubelet

未授权访问、kube-proxy

不安全配置。除此之外，还有很多组件都存在着类似的安全问题，比如

dashboard、Docker

等组件也存在未授权访问的隐患，这些都是

k8s

集群的重要系统组件，一旦被攻击成功，都是可以直接获得相应集群、节点或容器的权限。2.4.2

服务对外暴露攻击攻击点

5

表示

Node

节点对外暴露的服务。由于管理员的疏忽或为了方便管理而故意留的一些接口，导致内部服务的暴露，使得编排组件存在一个潜在的攻击点。比如

Mysql

对外服务存在弱口令登录的问题，目标系统的其中一个节点通过

NodePort

对外映射了

Mysql

服务端口，且经过尝试，通过弱口令可登27云原生安全威胁分析与能力建设白皮书录。这种情况就属于是管理员的安全意识不足引起的服务对外暴露风险，相应的攻击行为即服务对外暴露攻击。2.4.3

业务

pod

攻击在云原生环境下，上层应用程序对攻击者来说就像是集群的一个入口，攻击应用程序的目标就是突破入口，拿到业务环境也就是业务所在

pod

的

shell。攻击点

6

显示的是攻击者利用

Web

服务的漏洞对

pod

发起的攻击。Web

安全发展这么多年，可利用的漏洞非常之多，比如

Log4j2-RCE

漏洞（CVE-2021-44228）[12]以及

Spring-RCE

漏洞（CVE-2022-22965）[13]，其危害非常之大，且其利用也很简单。Log4j2

漏洞，虽然在高版本和低版本的JDK

环境下利用方法不同，但网上都已经分别有非常多的现成

EXP

可用，一旦成功利用即可以完全接管整个业务

pod。尽管进入

pod

后的权限仍然是受限的，但接下来可以通过尝试更多攻击手法，比如横向、逃逸等，逐步扩大战果，直至控制整个集群。对于

pod

发起的本地攻击，主要包括以下几个方面：信息收集:

进入一个新

pod

中，首先要做的就是收集当前环境的信息。通过信息收集，一是为后续攻击做准备，二是发现敏感服务和敏感信息,例如内网端口、k8s

组件端口等。提权：包括

pod

内提权和

k8s

提权，pod

内提权和容器的提权类似，详见容器安全内容。k8s

提权的方式和场景有很多，比如

RBAC

提权，还有一些用于

k8s

提权的

Nday，比如

CVE-2018-1002105、CVE-2020-8559

等。拒绝服务：主要从

CPU、内存、存储、网络等方面进行资源耗尽型攻击。28云原生安全威胁分析与能力建设白皮书2.4.4

集群环境下的横向攻击可能存在的横向攻击内容包括攻击

API

Server

以及攻击其他服务，如攻击路径

7、8

所示。攻

击

API

Server

：

k8s

集

群

的

pod

和

API

Server

通

信

是

通

过ServiceAccount

的

token

验证身份的，这里存在一个攻击点就是如果

pod的

ServiceAccount

权限过大，便可以以高权限和

API

Server

通信，则有可能查看集群的一些敏感信息或者执行高权限操作，甚至进一步控制集群。攻击其他服务：集群中往往会有一些通过

ClusterIP

暴露在内部的Service，这些服务在集群外部是扫描不到的，但是在内部

pod

中通过前文提到的信息搜集方法就有可能发现一些敏感服务，比如通过扫描端口或查看环境变量等。2.4.5k8s

管理平台攻击除了官方推出的

Dashboard，还有很多

k8s

管理平台，比如

Rancher、KubeSphere、KubeOperator

等，k8s

管理平台存在未授权访问、弱口令登录等安全风险。因为管理平台是直接控制着整个集群的，一旦出现安全问题，危害十分严重，从安全的角度讲，管理平台应该尽量避免暴露在外网。2.4.6

第三方组件攻击k8s

生态中还会使用一些第三方组件，比如服务网格、API

网关等，这些组件也有可能存在漏洞，比如开源

API

网关

Apache

APISIX[14]

的

RCE

漏洞、服务网格

Istio[15]

的未授权访问或

RCE

漏洞等。2.5

路径

4：微服务攻击29云原生安全威胁分析与能力建设白皮书微服务是一种软件架构模式，把一个应用拆分成多个服务，每个服务间通过约定的

API

接口方式进行通信，从而形成一个整体的应用系统。微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当前应用产生的故障不会影响到其他应用，单应用的负载也不会影响到其他应用。这其中每个拆分的服务就是微服务，彼此之间都是松耦合的，甚至可以使用各研发人员擅长的不同开发语言进行编写。图

9

展示了微服务场景下可能存在的攻击类型。图

9

针对微服务进行攻击的路径分析2.5.1API

攻击API

是一种计算接口，定义了软件之间的数据交互方式、功能类型。随着互联网的普及和发展，API

从早期的软件内部调用的接口，扩展到互联网上对外提供服务的接口。调用者通过调用

API，可以获取接口提供的各项服务，而无须访30云原生安全威胁分析与能力建设白皮书问源码，也无须理解内部工作机制的细节。针对微服务

API

的攻击，包括但不限于以下几个方面：缺少身份认证导致的攻击：某些

API

在设计之初由于未充分考虑用户群体或者具体的使用场景而未进行身份认证。身份认证的缺失导致相关

API

可被任意访问，若相关

API

涉及敏感数据则会埋下严重的数据泄漏的隐患。输入参数未校验导致的攻击：API

的参数组合及各参数值类型相对固定，这些参数也决定着

API

返回的数据。若

API

未对参数值的类型进行校验则可能会被攻击者利用来进行注入类攻击；若攻击者未将参数与用户身份进行关联则可能会导致越权类攻击。明文传输导致的攻击：API

未对传输数据进行加密设计而直接进行明文传输，攻击者可通过网络嗅探等手段直接获取

API

的交互格式以及数据，通过对获取的数据进行分析，并进行下一步的攻击。权限设计不合理导致的攻击：权限设计不合理可能导致水平越权、垂直越权和数据越权等攻击行为。水平越权，由于服务端在接收到客户端请求数据后进行操作时没有判断数据的所属对象，致使用户

A

可以访问到属于同一角色的用户

B的数据。垂直越权，由于服务端没有设置权限控制或权限控制存在缺陷，导致恶意用户只要猜测到管理页面的

URL

地址或者某些用于标识用户角色的参数信息等，就可以访问或控制其他角色拥有的数据，达到权限提升的目的。数据权限，某些

API

在设计时为兼容多个功能会将过多的数据杂糅到一起返回至前端，然后由前端去筛选相关的数据。这导致

API

返回过多的数据，攻31云原生安全威胁分析与能力建设白皮书击者可通过流量拦截等手段获取

API

原始返回的数据，从而存在数据泄漏的隐患。安全配置缺陷导致的攻击：安全配置缺陷是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储等问题所造成的攻击。2.5.2API

网关攻击微服务网关作为微服务后端服务的统一入口，它可以统筹管理后端微服务，API

网关提供路由、负载均衡、流量控制、服务发布等核心功能，API

网关在微服务架构中起到流量枢纽的作用。常用的

API

网关类型包括

Spring

CloudGateway[16]、Kong[17]、Zuul[18]等。不安全的微服务网关将给攻击者提供可乘之机，如

2022

年

3

月

1

日，Spring官

方

发

布

了

关

于

Spring

Cloud

Gateway

的

两

个

CVE

漏

洞

，

分

别

为CVE-2022-22946[19]

与

CVE-2022-22947[20]

。

攻

击

者

通

过

利

用CVE-2022-22947

漏洞，执行

SpEL

表达式，允许在远程主机上进行任意命令执行，获取系统权限。CVE-2022-22946

漏洞，将会导致网关能够使用无效或自定义证书连接到远程服务。2.5.3

微服务应用攻击微服务最终也是一个个独立的应用，也是通过代码方式进行编写的，也会使用一些开源的组件。因此在开发期间如果未做好安全开发管控与检测依然会引发相应的安全风险。如开发维护不当导致的安全漏洞，可能为

API

带来严重安全隐患，不法分子可通过安全漏洞、恶性

Bug

等因素获取敏感信息、造成服务器失陷。开发过程中引入开源或第三方插件、加载库、模块、框架等存在安全问题32云原生安全威胁分析与能力建设白皮书时，导致代码中出现安全漏洞、恶意代码、“后门”等安全隐患。2.6

路径

5：Serverless

攻击无服务器计算是一种云计算运行架构，在该架构下，云平台根据开发者编写好的代码，自动准备好相应的计算资源，完成运算并输出结果，从而大幅简化开发运维过程。无服务器计算作为事件驱动架构，将工作负载分解成多个无缝隔离的执行环境，每个执行环境都承载着一个特定任务并负责处理一个单独事件，在时间与空间中各自运行。例如，基于

Knative[21]实现的

Serverless

架构将无服务抽象为三个关键的组件，分别为构建应用的

build

组件、提供流量的

serving组件和生产消费事件的

event

组件。无服务器架构颠覆性的变化，给应用/服务开发商和拥有者带来了全新的安全挑战，包括攻击面增多、攻击方式复杂、可观测性不足、传统安全方案不兼容不适用等。图

10

展示了基于

Knative

实现的Serverless

场景下可能存在的攻击类型。图

10

针对

Knative

进行攻击的路径分析33云原生安全威胁分析与能力建设白皮书2.6.1

事件注入攻击无服务器计算本身是由事件驱动的，当函数订阅一个事件源后，该函数在该类型的事件发生时被触发，这些事件可能来源于平台内部或外部，其中部分事件可能是无法确认其来源的，对于来源未知且不可控的事件都是一种潜在的事件注入威胁。通常情况下，攻击者将可以控制的信息作为事件的一部分传递给可调用单元，可调用单元在得到事件后未对事件做合理的筛选和过滤，就直接对事件进行处理，此时就有可能产生数据注入风险，攻击者利用注入事件所携带的信息控制主机或造成数据泄露等。举例来说，可调用单元的事件还可能来自受攻击者控制的Web

请求。假设可调用单元直接使用事件携带的信息作为数据库访问请求的一部分。那么在这种情况下，攻击者将会使用精心构造的信息来修改数据库或读取机

密

信

息

。

有

关

无

服

务

器

应

用

程

序

的

注

入

攻

击

实

例

研

究

可

参

考

Top10Interpretation

for

Serverless[22]。2.6.2

敏感数据泄露攻击在无服务器计算体系结构中，敏感数据的暴露与在其他任何体系结构中一样令人担忧。传统体系结构中使用的大多数方法，如窃取密钥、执行中间人攻击以及在静止或传输中窃取可读数据，仍然适用于无服务器应用程序。然而，由于无服务器计算架构的存储共享特点，攻击者可以利用共享存储权限配置错误或漏洞窃取系统的敏感数据。全局信息泄露：无服务器计算架构中函数调用的不同服务通常也会被其它用户的函数调用来提供服务，无法像传统应用程序使用单个集中式配置文件存储的34云原生安全威胁分析与能力建设白皮书方式，因此开发人员多使用环境变量替代，使服务使用的敏感数据可能会留在容器中，并可能在函数的后续调用期间暴露。攻击者可以利用无服务器计算架构的这一特点，通过恶意程序植入等手段，获取服务中的全局敏感数据，造成敏感数据泄露。密钥的不安全存储：通常，服务被触发的时候需要访问特定的云或外部资源。要做到这一点，服务可能需要获取密钥。攻击者可以利用未安全存储的密钥或使用标准凭据集等情况发起攻击，造成严重的数据泄露等。像任何其他使用无服务器功能的应用程序一样，凭据和密钥的泄漏可能导致虚拟身份和数据泄漏。2.6.3

身份认证攻击Serverless

架构的应用是由几十甚至上百个函数组成，每个函数实现特定的业务功能，这些函数组合完成整体业务逻辑。一些函数可能会公开其

Web

API，需要进行身份认证，另一些则可能只允许内部调用，所以不用进行身份认证，这就使

Serverless

应用的整体身份认证变得复杂，你要为每个函数及事件源提供合理的身份认证机制，一不小心就会出错。如果一个函数提供了公开的

API

给用户使用，并且该

API

也有正确的身份认证逻辑，用户访问函数后，函数内部首先会从云存储读文件，然后将读取后的数据作为输入源调用内部函数，内部函数无须身份认证，如果云存储没有设置合适的身份认证，攻击者可能直接向云存储注入数据进行攻击。2.6.4

权限滥用攻击一个无服务器应用程序可以由数百个微服务组成。不同的功能、资源、服务和事件，所有这些都被编排在一起，以创建一个完整的系统逻辑。无服务器体系35云原生安全威胁分析与能力建设白皮书结构的无状态特性要求对每个资源进行仔细的访问控制配置，未遵循最小化权限的配置原则，配置了不适当的权限，将会增加事件驱动无服务器计算架构中的攻击面,使敏感数据更容易被窃取。2.6.5

拒绝服务攻击Serverless

平台具有自动化弹性扩展的特性，这就意味着用户只需要为函数的调用次数付费，函数的扩展交由云厂商负责。如果攻击者掌握了事件的触发器，并通过

API

调用大量的函数资源，那么在未受保护情况下函数将急速扩展，随之产生的费用也呈指数增长，最终会导致开发者的账户资金被消耗光，造成后续正常调用的拒绝服务。另外，即便受到保护的情况下，也未必可以完全规避风险，例如云厂商替开发者设置了调用频次上限，虽然开发者的钱包受到了保护，但攻击者也可以通过攻击频次达到设定上限实现了对开发者账户拒绝服务的目的。2.6.6

针对函数供应链的攻击无服务器计算的函数通常是功能单一的微服务，随着功能逻辑的复杂度提升，代码量也会随之增加，随之而来的供应链风险也愈发严重。例如利用基础镜像中已经存在的安全漏洞进行攻击、利用应用程序引入第三方依赖库的漏洞进行攻击等。36云原生安全威胁分析与能力建设白皮书三、典型攻击场景分析在对云原生关键技术的威胁全景进行分析后，本章通过复现典型攻击场景，深入分析攻击过程，使读者更加清晰、全面地了解云原生技术所面临的安全风险。3.1

镜像投毒攻击3.1.1

攻击场景介绍脏牛漏洞(CVE-2016–5195)[23]是

Linux

的一个本地提权漏洞，该漏洞的原因是

get_user_page

内核函数在处理

COW

的过程中，可能产出条件竞争造成

COW

过程被破坏，导致出现写数据到进程地址空间内只读内存区域的机会，攻击者即可利用该漏洞可以实现提权的目的。在容器环境下，攻击者通过利用含有脏牛漏洞的二进制程序，构建恶意镜像，并上传到公共镜像仓库引诱用户下载。当受害者下载并启动了该恶意镜像后，攻击者便可以接收到恶意镜像反馈的监听信息，即可通过反弹

shell

窃取敏感数据、进行危险操作等攻击行为，攻击路径如图

11

所示图

11

镜像投毒攻击路径分析37云原生安全威胁分析与能力建设白皮书3.1.2

攻击过程复现步骤

1：构建二进制漏洞利用程序。步骤

2：基于

Ubuntu

镜像构建恶意镜像，将上一步中的二进制漏洞利用程序作为镜像的入口点（entrypoint）步骤

3：先使用

nc

等工具开启反弹

shell

监听，然后执行如下命令模拟受害者创建并运行容器即可，效果如图

12

所示：图

12

反弹

shell

攻击结果展示3.2

挂载

Docker

Socket

导致容器逃逸攻击3.2.1

攻击场景介绍Docker

通过将主机上的目录或文件挂载到

Docker

容器中，以实现数据的共享或持久化，详细命令可参考

Docker

CLI[24]，其中挂载命令如下：Docker

run

...-v

[主机目录]:[容器目录]在容器的使用过程中，Docker.sock

文件是

Docker

守护进程的

Unix

套接38云原生安全威胁分析与能力建设白皮书字（Unix

Socket），它是用于与

Docker

守护进程通信的一种机制。通过这个套接字，可以通过发送命令和接收结果来与

Docker

守护进程交互。在使用

Docker命令行工具或者

Docker

API

时，都会通过这个套接字与

Docker

守护进程进行通信。将宿主机上的

docker.sock

文件挂载到容器内部，将会导致容器逃逸风险。3.2.2

攻击过程复现步骤

1：创建一个容器，并在容器中挂载/var/run/Docker.sock

文件docker

run

-itd

--name

with_Docker_sock

-v

/var/run/Docker.sock:/var/run/Docker.sock

ubuntu步骤

2：在容器安装

Docker

命令行客户端，内执行以下命令：apt-get

updateapt-get

install

curlcurl

-fsSL

https://get.D/

|

sh步骤

3：在容器内部创建一个新的容器，并将宿主机目录挂载到新的容器docker

run

-it

--name

container_in_container

-v

/:/host

ubuntu

/bin/bash操作结果如图

13

所示，可以看出，新启动的容器

container_in_container可以越权查看到主机相关目录信息。39云原生安全威胁分析与能力建设白皮书图

13

容器逃逸结果展示3.3k8s

权限提升攻击3.3.1

攻击场景介绍k8s

通过

RBAC[25]来实现用户权限管理，k8s

提供了四种

RBAC

对象，分别

为

Role

、

ClusterRole

、

RoleBinding

和

ClusterRoleBinding

。

Role

及ClusterRole

分别为某些权限的集合，例如

Pod

的“get”、“watch”和“list”权限，RoleBinding

和

ClusterRoleBinding

资源则是将这些权限与特定的用户进行绑定。CVE-2018-1002105[26]是一个

k8s

提权漏洞，该漏洞允许攻击者在拥有pod

权限的情况下，提升至

API

Server

权限，当拥有

API

Server

权限后，就可以轻而易举的攻陷宿主机。攻击路径如下图所示，攻击者向

API

Server

发送经过构造的错误请求，将自己的权限提升为

API

Server

的权限,

创建挂载宿主机资源的

Pod，实现容器逃逸。图

14

展示了攻击者利用

k8s

提权漏洞进行攻击的路径。40云原生安全威胁分析与能力建设白皮书图

14

k8s

权限提升攻击路径3.3.2

攻击过程复现攻击流程如下大致攻击流程如下：1.

构造错误请求，建立经

k8s

API

Server

代理到

Kubelet

的高权限websocket

连接。2.

利用高权限

websocket

连接，向

Kubelet

发起/runningpods/请求，获得当前活动

Pod

列表。3.

从活动

Pod

列表中找到

k8s

API

Server

的

Pod

名称。4.

利用高权限

websocket

连接，向

Kubelet

发起/exec

请求，指定

Pod为上一步中获得的

Pod

名称，携带“利用

cat

命令读取‘ca.crt’”作为参数，从返回结果中保存窃取到的文件。5.

利用高权限

websocket

连接，向

Kubelet

发起/exec

请求，指定

Pod为上一步中获得的

Pod

名称，携带“利用

cat

命令读取‘apiserver-kubelet-client.crt’”作为参数，从返回结果中保存窃取到的文件。41云原生安全威胁分析与能力建设白皮书6.

利用高权限

websocket

连接，向

Kubelet

发起/exec

请求，指定

Pod为上一步中获得的

Pod

名称，携带“利用

cat

命令读取‘apiserver-kubelet-client.key’”作为参数，从返回结果中保存窃取到的文件。7.

使用

kubectl

命令行工具指定凭证为

4、5、6

步中窃取到的文件创建挂载了宿主机根目录的

Pod，实现容器逃逸。攻击结果如图

15

所示，漏洞利用程序成功利用漏洞从

k8s

API

Server

Pod中窃取了高权限凭证。图

15

利用

CVE-2018-1002105

窃取高权限凭证由于攻击步骤代码过长，详细的攻击源码见

Exploit.py

脚本[27]，其中实现构造越权请求的的代码如下：42云原生安全威胁分析与能力建设白皮书def

_try_to_get_privilege(ssock,

namespace,

pod):payload1

=

http_delimiter.join((f'GET

/api/v1/namespaces/{namespace}/pods/{pod}/exec

HTTP/1.1',host_header,auth_header,upgrade_header,conn_header))payload1

+=

http_delimiter

*

2ssock.send(payload1.encode('utf-8'))正常的请求地址中带有

stdin、stout

和

tty

三个参数，该代码中构造的错误请求/api/v1/namespaces/{namespace}/pods/{pod}/exec

未包含对应的参数，由此利用系统漏洞代理到

Kubelet

的高权限

websocket

连接[28]。3.4Istio

认证策略绕过攻击3.4.1

攻击场景介绍Istio

目前已作为微服务治理框架的代表，在

Istio

中

JWT

认证策略通常通过配置一个

YAML

文件实现，以下是一个简单的

JWT

认证策略配置。43云原生安全威胁分析与能力建设白皮书apiVersion:

"authentication.istio.io/v1alpha1"kind:

"Policy"metadata:name:

"jwt-example"namespace:

istio-systemspec:targets:-

name:

istio-ingressgateway

#需要在

Istio

网关入口处部署

JWT

认证策略origins:-

jwt:issuer:

"test@istio.io"

#JWT

颁发者jwksUri:

"/jwks.json"

#用于验证

JWT

的

JWKS

所在

URLtrigger_rules:

#JWT

验证请求的触发规则列表-

included_paths:

#代表只有访问包含以下路径规则才需要

JWT

认证-

exact:

/productpage

#路径与

productpage

完全匹配后才可以访问服务CVE-2020-8595

漏洞[29]主要由于

Istio

JWT

策略配置中的

triggerRules机制，简单来讲，triggerules

指定请求

url

的字符串匹配机制，如上

YAML

文件中参数

exact，表示需要完全匹配的字符串才可以满足要求，包括

url

后面所附带的参数（“?”）以及

fragments

定位符（"#"），而不是在匹配之前将“?”和“#”隔离的内容进行分离。导致攻击者可以通过在受保护的

path

后添加“?”或“#”进行绕过从而达到未授权（JWT）访问。44云原生安全威胁分析与能力建设白皮书3.4.2

攻击过程复现为了复现攻击过程，用户可以参照文章[30]搭建测试环境，包括

k8s

及

Istio集群环境，httpbin

服务、gateway、部署

JWT

策略以及设置相应的环境变量等。攻击过程复现如下：首先，访问加了

JWT

认证的

url

path

“/ip”，结果如图

16

所示：图

16

未授权访问结果可以看到服务端返回

401

Unauthorized

拒绝访问，原因是需要认证授权，证明策略生效了。

然后我们再通过添加符号“？”，绕过

Istio

JWT

认证策略配置，结果图

17

所示：图

17

绕过

Istio

JWT

认证访问结果45云原生安全威胁分析与能力建设白皮书可以看到返回为

200

状态码，说明不需要

JWT

的认证也可以访问

ip

这个

path下的内容，从而完成绕过。46云原生安全威胁分析与能力建设白皮书四、云原生应用保护能力建设开展云原生应用保护能力建设，可以助力企业的云原生安全体系形成，增强云原生应用的内生安全能力，保障云原生应用的安全运行。CNAPP

首先由

Gartner

在

2021

年提出[31]，CNAPP

包含一组集成的安全性和合规性的功能，旨在开发和生产过程中保护云原生应用全生命周期的安全，确保了在开发和运营生命周期中的全面保护云原生应用的安全。2023

年中国信息通信研究院在云原生产业联盟年会上发布了《云原生应用保护平台能力要求》[32]，为云原生应用保护平台提出了具体的能力要求。在此基础之上，中国联通研究院积极开展云原生应用保护能力建设实践，并提出了云原生应用保护能力建设架构图，如图

18

所示。图

18

云原生应用保护能力建设架构图4.1

制品安全能力建设制品安全主要从代码安全、镜像安全、制品环境安全和安全检测四个层面进行安全能力构建。制品安全能力建设如图

19

所示。47云原生安全威胁分析与能力建设白皮书图

19

制品安全能力建设4.1.1

代码安全云原生安全的建设是与传统的安全建设是相交织的，云原生环境下，新增了许多传统安全无法覆盖的资源对象，以及在相同场景下但不适用云原生环境的安全能力。代码作为企业最核心的资产，其安全性在传统安全与云原生安全都极为重要，代码的风险主要来自于代码数据丢失、泄露，以及编码中引入风险漏洞。在代码安全方面，需重点考虑静态应用安全测试和软件成分分析两个方面。（1）静态应用安全测试SAST

与人工代码审查相比，具有效率高、结果一致等优点，属于白盒测试的一种。利用

SAST

工具进行检测不需要运行测试的应用程序，而且理论上可以覆盖所有可能的程序路径，检测出来的漏洞多而全，但由于未对运行应用程序进行检测，因此

SAST

工具检测出的风险会存在一定程度的误报。（2）软件成分分析48云原生安全威胁分析与能力建设白皮书SCA

针对第三方开源软件以及商业软件涉及的各种源码、模块、框架和库进行分析、清点和识别，通过分析开源软件的组件及其构成和依赖关系，识别出已知的安全漏洞，并提供相应的修复建议，能够有效的帮助开发人员修复安全问题，从而把这些风险排查在应用系统投产之前，对开源组件及风险进行统一管理。开源组件信息统一管理：在现今开源组件大量使用情况下，需对所有的开源组件库的信息进行统一管理，用于有效追踪、监视和管理应用程序中使用的各种开源组件。包括记录组件的版本、许可证等信息以及与组件相关的其他元数据。这有助于组织在应用程序中使用的