基于 KBOM 保障 Kubernetes 组件安全

unsetunset摘要unsetunset

本文旨在探讨供应链安全与云原生安全交叉领域的一项研究及应用——KBOM（Kubernetes Bill of Materials）。

在 Leaky Vessels 漏洞导致全球范围内容器逃逸的背景下，文章首先分析了 Kubernetes 架构的演变及其生态环境，进而揭示了 Kubernetes 组件的安全现状。

在此基础上，本文介绍了 KBOM 概念，旨在探讨业界人士为了增强 Kubernetes 组件的安全性所进行的尝试。

此外，文章进一步深入探讨了 KBOM 的核心理念和应用场景，并详细记录了为实现 KBOM 漏洞扫描器所进行的研究尝试与探索过程。

unsetunset关键词unsetunset

云原生安全、供应链安全、Kubernetes 组件安全、KBOM、漏洞扫描

unsetunset引言unsetunset

在容器安全领域，runc 组件的安全漏洞屡次成为焦点。

回溯到 2019 年，CVE-2019-5736 漏洞，即“Runcescape”，由波兰研究人员 Adam Iwaniuk 和 Poplawski 发现，该漏洞使得攻击者能够获取宿主机的 root 权限，引发了安全社区的广泛关注。

如今，CVE-2024-21626 漏洞再次敲响警钟，其广泛影响激起了技术界的热议。

随着 Kubernetes 架构的持续发展，runc 等关键组件的安全问题日益凸显，引发了对 Kubernetes 组件安全现状的深刻思考。

unsetunset一、背景unsetunset

（一）Leaky Vessels 漏洞

2023 年 11 月 20 日，Snyk 的安全研究员 Rory McNamara 发现了核心容器基础设施组件中的四个安全漏洞，统称为 Leaky Vessels 漏洞，如表 1 所示。

表 1：Leaky Vessels 的漏洞概览

在对漏洞进行验证后，Snyk 迅速启动了负责任的漏洞披露流程 。整个流程经历了 72 天，期间 Snyk 还发布了动态和静态的检测工具，以供组织进行检测。

直至 2024 年 2 月 1 日，国内安全厂商才发布漏洞预警，各行业公司随即展开了应急响应。

表 2：Leaky Vessels 的漏洞披露流程

（二）CVE-2024-21626 漏洞

Leaky Vessels 漏洞中，CVE-2024-21626 的影响范围最为广泛。

在 runc 1.11 及更早的版本中，由于内部文件描述符泄漏的问题，攻击者可以让新生成的容器进程在宿主文件系统命名空间中拥有工作目录，从而允许通过访问宿主文件系统实现容器逃逸。

此外，恶意镜像也可以使用相同的攻击，令容器进程通过 runc run 访问主机文件系统。

表 3：受 CVE-2024-21626 影响的常见的组件

这些攻击的不同形式都可以用来覆盖宿主机上的一些特定程序文件，以实现从容器内部完全逃逸到宿主机。

据 Dark Reading 报道，Leaky Vessels 漏洞事件触发了全球范围内的容器逃逸现象 ；Wiz 推测，至少有 80%的云环境可能会受到该漏洞的影响 ；而阿里云基于其庞大的数据资源，评估出全网至少有 100,000 个应用可能遭受该漏洞的影响 。

鉴于 runc 是一个底层的容器运行时，能够基于 Linux 内核创建并运行容器，成为了几乎所有的容器引擎调用的第三方库，因此该漏洞的影响范围扩展至包括 Containerd、Docker Engine 等众多基于 runc 特定版本构建的下游组件及软件。

（三）总结

值得注意的是，runc 并非首次被披露出影响范围如此广泛的漏洞了。

2019 年 2 月 11 日，波兰研究人员 Adam Iwaniuk 和 Poplawski 在研究 namespace 沙盒时，无意间在 runc 中发现了 CVE-2019-5736 漏洞，并命名为 Runcescape，该漏洞同样允许攻击者获取宿主机的 root 访问权限。

与 CVE-2019-5736 漏洞类似，CVE-2024-21626 漏洞同样引起了广泛的关注，众多技术博客和商业公司均对该漏洞进行了专题讨论。

不同的是，随着 Kubernetes 架构的不断演进，runc 等组件的安全漏洞事件引发了我们对 Kubernetes 组件安全现状的担忧。

unsetunset二、Kubernetes 组件安全现状unsetunset

（一）Kubernetes 架构及生态

容器的生态系统由新兴技术、众多专业术语以及相互竞争的大型企业组成。

这些企业偶尔会暂停竞争，共同建立如 CRI、CNI 以及 CSI 等标准，以促进整个生态系统的互操作性，从而允许组织在不同的平台和操作系统上运行容器，减少对单一项目的依赖。

Kubernetes 于 2022 年 5 月 4 日发布了 v1.24.0 版本，在该版本中已彻底移除了 dockershim 插件，这标志着 Kubernetes 已正式结束对 Docker 容器运行时的原生支持了 。

随着时间的推移，Kubernetes 允许接入多种运行时组件、网络组件和存储组件，逐步演变成一个与容器无关的编排平台了。

伴随着架构的变化，Kubernetes 的第三方生态系统也得到了蓬勃的发展。组织可根据 CNCF 发布的云原生蓝图，按需选择适合的组件、插件和工具 。

然而，丰富的选择也带来了相应的风险。我们对云原生蓝图中所提及的部分组件的安全公告进行了初步的采集 ，发现近年来云原生组件的漏洞数量呈现出上升的趋势，且越为通用的组件，其漏洞数量增长越迅速。

(二)、Kubernetes 威胁建模

在 Kubernetes 的威胁建模中，组件安全占据着核心地位。

• 在 CNCF 提出的云原生安全 4C 模型中，集群组件安全被称为集群（Cluster）安全的三大要素之一 ；

• 在微软构建的 Kubernetes ATT&CK 威胁矩阵中，容器逃逸技术的主要影响因素为运行时组件本身的漏洞 ；

• OWASP 在发布 Kubernetes Top 10 时，将“过时且易受攻击的 Kubernetes 组件”列为十大安全风险之一 ；

• CNCF 金融服务用户组在采用 STRIDE 方法对 Kubernetes 进行威胁建模时，先对 Kubernetes 组件进行审查，再识别平台内信任边界处的潜在安全问题 。

（三）总结

随着 Kubernetes 架构的演变以及生态系统的蓬勃发展，集群组件的安全受到了业界的广泛关注。

然而，与单个容器安全防护的应用实践相比，容器编排整体安全防护仍然缺乏有效的落地方案。

此外，针对 Kubernetes 的安全防护措施，也主要依赖于配置扫描以及容器镜像漏洞检测。

此后，业界对于 Kubernetes 组件安全的关注相对较少，且呈现出一定程度的滞后。

unsetunset三、Kubernetes 物料清单（KBOM）unsetunset

（一）首个 KBOM 标准颁布

为了有效应对 Kubernetes 组件所面临的安全风险，Kubernetes 安全运营中心（Kubernetes Security Operations Center，简称 KSOC）于 2023 年 5 月 8 日发布了首个 Kubernetes 物料清单（Kubernetes Bill of Materials，简称 KBOM）标准，并开源了可为集群自动生成物料清单的名为 KBOM 的工具。

KBOM 作为一种新确立的标准，每当被提及时，往往会与 Kubernetes 的软件物料清单（Software Bill of Materials，简称 SBOM）一同讨论，以进行区分并避免混淆。

Kubernetes 的 SBOM 侧重于单个容器的安全性，主要通过遍历容器镜像的文件系统，解析其中的软件包信息，以识别出系统层与软件层的软件包及其依赖关系。

SBOM 在法规性文件中已较为成熟，最早在 2014 年美国国会众议院的《网络供应链管理与透明度法案》中被提及 。

相较之下，KBOM 的聚焦于 Kubernetes 平台本身的安全。其主要通过向 API Server 发送 HTTP(S)请求，解析所响应的 JSON 数据，以对集群资源及其运行的组件（如 API Server、Etcd 和 Containerd 等）进行收集。

KBOM 作为云原生安全与供应链安全交叉领域的一项新兴技术，在 2023 年首次被提出 。

（二）KBOM 的生成

为了方便开发与测试，在生成集群的 KBOM 的过程中，我们建议采用 kind 工具在本地创建并启动一个集群。

随后根据系统提示，对集群信息进行收集。若要深入理解 API Server 的交互细节，可将日志级别调整至 7 级，以便详细监控和记录 HTTP(S) 数据包的通信过程。

然后，使用 Kubernetes 提供的客户端库来管理和操作集群资源，以提高集群信息获取的自动化程度。例如，Go 语言的 k8s.io/client-go 库便封装了一系列与 Kubernetes API Server 交互的接口，可帮助我们自动收集元数据、节点信息、组件信息以及镜像信息。

在成功获取到这些信息后，只需进一步将其转换成 KSOC 所定义的 KBOM 标准格式，即可对集群进行安全审计和管理 。

（三）KBOM 的数据结构

KBOM 包含了集群信息、节点信息以及组件信息等数据，有助于组织对集群的整体安全进行评估。

以本文第一部分所提及的 CVE-2024-21626 漏洞为例，该漏洞导致容器逃逸的主要原因在于 runc 在使用 openat2 系统调用时未能正确关闭文件描述符。

值得注意的是，Linux 内核在 5.6 版本之前并未实现 openat2 系统调用。因此，若容器引擎运行在 5.6 版本之前的 Linux 内核上，那么它将不会受到该漏洞影响 。

为了帮助组织快速评估其集群是否受此漏洞影响，KBOM 提供了内核版本和容器运行时版本等关键信息。

此外，KBOM 还提供了 Kubernetes 版本、kubelet 版本、kube-proxy 版本以及各组件镜像等信息，以便于组织对集群组件安全进行快速评估。

如表 4 所示，在对 KBOM 所包含的信息进行分析后，我们观察到：

• 相对于基础设施物料清单（Infrastructure Bill of Material，简称 IBOM），KBOM 补全了 IBOM 在 Kubernetes 特定内容方面的缺失。例如：集群中运行的容器镜像以及与之交互的第三方生态系统信息。

• Kubernetes 的 SBOM 则仅限于镜像的物料清单，它并未包含控制平面或自定义资源中使用的第三方镜像信息。相比之下，KBOM 关注于 Kubernetes，能够全面涵盖集群中的各个组件，包括控制平面和自定义资源。在对集群的组件进行安全评估时，能够迅速地识别出相关的 CVE 漏洞。

表 4：0.3.1 版本的 KBOM 所包含的最新信息（截止至 2024 年 12 月 30 日）

（四）KBOM 的使用场景

对 KBOM 的数据结构进行分析后，我们可将 KBOM 的使用场景归纳为跨团队共享集群配置和快速识别集群中的 CVE 漏洞两方面。

尽管 Kubernetes 被誉为云操作系统，但其始终缺乏一种高效的机制来跨团队共享集群配置及其参数。

为此，KBOM 提供了一种通用的解决方案，可用于共享集群的物料清单。

它详尽地阐述了集群的托管模型、节点数量、对象信息、公共镜像以及自定义镜像等关键细节，从而能够精确地描绘出集群的全貌，有助于团队成员之间就集群的成本、合规性和安全性进行更为深入的讨论和决策。

另外，由于 Kubernetes 的许多第三方组件都是开源的，并且它们通常会在其代码仓库中发布安全公告。

组织可通过监控这些数据来保持对组件安全风险的警惕性。通过从 KBOM 中提取出组件的版本和配置信息，组织可快速对集群组件进行安全评估，从而及时发现潜在的安全漏洞并采取相应的修复措施。

这种方法极大加快了漏洞的检测和响应过程，从而提高了集群的整体安全水平。

（五）总结

为了缓解 Kubernetes 组件安全，KSOC 于 2023 年发布了首个 KBOM 标准并开源了可自动生成 KBOM 的开源工具。

KBOM 聚焦于 Kubernetes 平台的整体安全，弥补了 IBOM 和 Kubernetes SBOM 的不足，更适合跨团队共享集群配置以及集群组件漏洞检测。

unsetunset四、KBOM 漏洞扫描器unsetunset

（一）漏洞扫描原理

在深入探讨了 KBOM 的概念及其应用场景之后，我们将以开发 KBOM 漏洞扫描工具作为我们的主要实践目标。

如前所述，我们可以通过调用 GitHub 的 REST API 接口来获取安全公告数据 ，进而提取出受漏洞影响的版本信息，并将其与集群 KBOM 中的版本信息进行比对。

然而，与 CNCF 的大多开源组件不同的是，Kubernetes 的安全公告数据为非结构化数据，主要存储在 Github Issue 中，并被打上“official-cve-feed”标签。

因此，在实验验证成功之后，我们投入了大量时间研究如何自动化处理这些非结构化的安全公告数据。

（二）又一个 KBOM 概念提出

这时，Aqua Security 推出了新的 KBOM 概念 ，主要从关键组件视角对集群信息进行搜集，涵盖了控制平面组件、节点组件以及插件组件。

Aqua Security 并不将 KBOM 视为新标准，而是认为它应与其他 BOM 格式兼容，并计划将 KBOM 安全扫描功能集成到开源工具 Trivy 中。

次日，我们与 Aqua Security 的开源副总裁、CNCF 大使 Itay Shakury 就 KBOM 的相关问题进行了深入交流。

在对话中，Aqua Security 表达了他们的愿景：“希望 Trivy 能够提供原生的 KBOM 生成功能，正如市面上已有多种工具能够生成 SBOM，但 Trivy 依然提供了原生的 SBOM 生成功能。此外，在研究 KBOM 之初，KSOC 尚未发布 KBOM 的标准，我们认为 KBOM 应作为一个概念而非标准，并应与 CycloneDX 格式兼容。尽管如此，我们后来仍尝试与 KSOC 团队取得联系，但由于种种原因，未能实现合作。”

在交流过程中，我们注意到问题关键点可能在于：Aqua Security 在开展相关工作时，KSOC 尚未发布 KBOM 的标准。

这一点在与 Itay 的初次交流中可见一斑，他最初仅就 Kubernetes SBOM 与 KBOM 的区别进行了回复。在得知 KSOC 发布的 KBOM 标准和工具后，他删除了原先的回复，并在两天后重新作出回应，此时他们尚不知 KSOC 已支持 CycloneDX 格式。

在本次交流过程中，我们初步认识到 KBOM 不仅在规范管理、数据格式及标准文件方面存在缺失，且在宣传推广、资料准备、社区及生态支持方面亦显不足。

为防止类似状况再次出现，并考虑到 Aqua Security 拥有更为充沛的人力以及丰富的云原生安全经验，我们决定暂缓相关项目工作。此举旨在观察 Aqua Security 具体如何定义 KBOM 并将其进行落地和应用。

2023 年 10 月 14 日，首个 KBOM 漏洞扫描功能在开源工具 Trivy 中得以实现 。Trivy 首先需要为集群生成 CycloneDX 格式的 KBOM，随后利用其 SBOM 扫描功能对生成的 KBOM 进行漏洞检测。

与我们的预期有所差异的是：Trivy 当前的 KBOM 扫描功能主要局限于 API Server、Kubelet 以及 Kube Proxy 等核心组件。对于我们所关注的 Kubernetes 第三方生态组件的漏洞检测却尚未涵盖。展望未来，我们仍需在 KBOM 漏洞检测领域投入大量工作。

(三) 总结

在深入探讨了 KBOM 的概念及其应用场景之后，我们开始了 KBOM 漏洞扫描器的开发工作。然而，开发过程亦存在许多挑战，例如，该如何自动处理非结构化的安全公告数据。

在此期间，Aqua Security 提出了 KBOM 的新理念，并发布了首个 KBOM 漏洞扫描器。通过与 Aqua Security 团队的深入交流，我们意识到了 KBOM 在非技术层面的局限性，并开始思考：KBOM 究竟应该是一个标准还是仅仅停留在概念层面？KBOM 是否需要一个标准？

unsetunset五、总结与展望unsetunset

（一） KBOM 的优势

毫无疑问，KBOM 的应用为集群的透明度提供了保障，使得对集群安全风险的全面评估和快速应急响应成为可能。

此外，KBOM 的生成成本相对较低，与 SBOM 不同，它无需遍历文件系统或对镜像内容进行分析，也不需要与大量开发者的多样化版本管理策略相兼容。KBOM 的创建仅通过向 API Server 发起 HTTP 请求即可实现。

在业务环境中，KBOM 亦具备广泛的应用场景，例如，可用于跨团队共享集群信息，以及对集群组件的漏洞进行全面的安全评估。

（二） KBOM 的不足

然而，我们必须正视 KBOM 技术当前存在的一些局限性。

首先，KBOM 作为一个新兴技术，其成熟度尚显不足，缺乏统一的管理规范和数据格式标准。例如，在无任何工作负载的单个 Kubernetes 集群中，KSOC 生成了超过 5,000 条数据记录，而 Trivy 仅生成了 50 余条。在处理大规模 Kubernetes 集群时，直接通过访问 API Server 生成 KBOM 可能会导致速度显著下降，因此，考虑从缓存中读取集群信息等优化策略是必要的。

其次，KBOM 缺乏正式的标准。尽管 SBOM 的概念已有十年历史，并在 2022 年已被纳入合规性法规文件中，但 KBOM 尚未被任何正式文件所采纳。

最后，KBOM 在社区支持和公开资料方面也存在不足。由于宣传推广不足，导致 Aqua Security 重复开展了相似的工作。KBOM 的生态系统和社区尚未完全建立，因此，尽管 KSOC 提出了相关标准，但支持该标准的工具和生态尚未得到充分开发和完善。此外，关于 KBOM 的研究资料相对匮乏，目前公开可获取的资料中，缺乏深入的分析和解读。

（三） 总结

正如许多在实验室中孕育的创新技术一样，KBOM 要在实际业务环境中发挥其真正的潜力，不仅需要吸引更多技术人员的参与研究，还必须在更加多元化的应用场景中进行测试应用，以确保其安全能力和稳定性。

同时，企业的高层管理者也必须在 KBOM 所提供的安全保障与所需的成本投入之间找到恰当的平衡点。

若您对这个研究感兴趣，欢迎加入我们的读者群，与我们一起探索云原生安全的奥秘😺～

unsetunset参考文献：unsetunset

[1]. Snyk. "Leaky Vessels: Docker and runc Container Breakout Vulnerabilities." Available: https://snyk.io/blog/leaky-vessels-docker-runc-container-breakout-vulnerabilities/.

[2]. Snyk. "Leaky Vessels Dynamic Detector." Available: https://www.github.com/snyk/leaky-vessels-dynamic-detector.

[3]. Snyk. "Leaky Vessels Static Detector." Available: https://github.com/snyk/leaky-vessels-static-detector.

[4]. Dark Reading. "Leaky Vessel: Cloud Bugs and Container Escapes Globally." Available: https://www.darkreading.com/cloud-security/leaky-vessel-cloud-bugs-container-escapes-globally.

[5]. Wiz. "Leaky Vessels: Container Escape Vulnerabilities." Available: https://www.wiz.io/blog/leaky-vessels-container-escape-vulnerabilities.

[6]. Alibaba Cloud. "CVE-2024-21626 Details." Available: https://avd.aliyun.com/detail?id=CVE-2024-21626.

[7]. The New Stack. "What You Need to Know About the runc Container Escape Vulnerability." Available: https://thenewstack.io/what-you-need-to-know-about-the-runc-container-escape-vulnerability/.

[8]. Kubernetes. "Changelog 1.24: Dockershim Removed from Kubelet." Available: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#dockershim-removed-from-kubelet.

[9]. CNCF. "Cloud Native Landscape." Available: https://landscape.cncf.io/.

[10]. Miao2sec. "Cloud-Native Security Vulnerabilities." Available: https://github.com/miao2sec/cloud-native-sec-vuln.

[11]. Trend Micro. "Securing the 4 Cs of Cloud-Native Systems: Cloud, Cluster, Container, and Code." Available: https://www.trendmicro.com/vinfo/us/security/news/virtualization-and-cloud/securing-the-4-cs-of-cloud-native-systems-cloud-cluster-container-and-code.

[12]. Microsoft. "Secure Containerized Environments with Updated Threat Matrix for Kubernetes." Available: https://www.microsoft.com/en-us/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/.

[13]. OWASP. "Kubernetes Top Ten." Available: https://owasp.org/www-project-kubernetes-top-ten/.

[14]. CNCF Financial User Group. "Kubernetes Threat Model." Available: https://github.com/cncf/financial-user-group/tree/main/projects/k8s-threat-model.

[15]. Rad Security. "KBOM: Kubernetes Bill of Materials." Available: https://github.com/rad-security/kbom.

[16]. U.S. Congress. "House Bill 5793 (113th Congress)." Available: https://www.congress.gov/bill/113th-congress/house-bill/5793.

[17]. Rad Security. "KSOC Releases the First Kubernetes Bill of Materials (KBOM) Standard." Available: https://rad.security/blog/ksoc-releases-the-first-kubernetes-bill-of-materials-kbom-standard.

[18]. Kubernetes SIGs. "Kind: Kubernetes IN Docker." Available: https://github.com/kubernetes-sigs/kind.

[19]. Rad Security. "KBOM Internal Kubernetes Implementation." Available: https://github.com/rad-security/kbom/blob/main/internal/kube/kube.go.、

[20]. BestWing. "CVE-2024-21626: Container Escape." Available: https://bestwing.me/CVE-2024-21626-container-escape.html.

[21]. GitLab. "Introducing the Infrastructure Bill of Materials." Available: https://about.gitlab.com/blog/2022/09/22/introducing-the-infrastructure-bill-of-materials/

[22]. Miao2sec. "Collection of Cloud-Native Security Vulnerabilities." Available: https://github.com/miao2sec/collect-cloud-native-sec-vuln.

[23]. Aqua Security. "Introducing KBOM: Kubernetes Bill of Materials." Available: https://www.aquasec.com/blog/introducing-kbom-kubernetes-bill-of-materials/.

[24]. Aqua Security. "Trivy Discussions: KBOM Support." Available: https://github.com/aquasecurity/trivy/discussions/5377.