Securing the AI supply chain on GKE: Introducing k8s-aibom for automated AI BOMs

在 GKE 上引入 k8s-aibom 用于自动化 AI 物料清单 | Google Cloud 博客

安全与身份

在 GKE 上保障 AI 供应链安全：推出用于自动化 AI 物料清单的 k8s-aibom

2026 年 7 月 14 日

##### Glen Messenger

集团产品经理

##### 今天立即试用 Gemini Enterprise Business Edition

进入职场 AI 的大门

立即试用

安全团队应该如何管理影子 AI？开发人员部署的未正式注册工作负载通常会规避传统安全扫描器，因为组织不愿通过要求特权 Daemonsets、内核级访问权限和手动 pod-spec 编辑来减缓开发进度并破坏稳定性。

为打破这一僵局，今天我们开源了 k8s-aibom。这个轻量级、无特权的 Kubernetes 控制器持续监控集群 API 和容器环境，可自动检测运行中的 AI 运行时（如 vLLM 和 Triton）并生成标准的 CycloneDX 机器学习物料清单（ML-BOM）。

通过提供直接从运行时执行获得的自动化、审计级可见性——无论工作负载是否正式注册——k8s-aibom 可帮助团队在不产生开发人员集成摩擦的情况下，安全地将 AI 项目从试点阶段推进到生产环境。

零摩擦架构

k8s-aibom 从底层架构设计上兼顾了 CISO 对全面可见性的要求和 SRE 对集群稳定性的要求。它以 k8s-aibom-system 命名空间中的单个无特权 Deployment 形式部署。它完全无需开发人员参与——无需 Sidecar 容器、无需 eBPF 内核模块、无需特权 DaemonSets，也无需修改现有开发人员 Pod 规格。

k8s-aibom 监控 AI 工作负载并生成物料清单。

发现流程通过四个清晰阶段执行：

• 抓取集群工作负载：控制器持续监控集群中的 KServe 资源、Deployments、StatefulSets、DaemonSets 和 Jobs。
• 识别 AI 堆栈：高级模式匹配检查容器镜像、环境变量和命令行参数，以检测服务运行时（vLLM、Triton 推理服务器、TGI、Ollama）、自主代理框架（LangChain、AutoGen、CrewAI）、向量数据库和 RAG 存储（Milvus、Qdrant、pgvector），以及分布式训练任务和评估套件。
• 生成标准清单：控制器将发现的工件编译为正式的 OWASP CycloneDX 1.6 机器学习物料清单（ML-BOM）文档。
• 导出到目标：控制器将生成的 ML-BOM 直接附加到集群内 AIBOM 自定义资源（CR）的自定义资源状态（status.bomDocument）中，并将其路由到可选的外部目标，包括 Google Cloud Storage 存储桶和外部 Webhook 端点。

应用团队无需修改 Pod 规格、注入 Sidecar 容器或更改持续集成和持续交付（CI/CD）流程。此外，k8s-aibom 将 Kubernetes 集群状态视为纯函数输入：相同的集群输入会生成字节级相同的 ML-BOM 文档。这种确定性特性使 k8s-aibom 非常适合 GitOps 工作流，使站点可靠性工程师（SRE）能够执行精确的差异对比，并在 AI 依赖项发生偏移时触发精确的变更检测警报。

现有 AIBOM 工具的局限性

许多AI BOM解决方案提供构建时扫描器，通过静态工件生成BOM。这些工具帮助您追踪计划部署的代码。

商业AI安全平台通过云原生姿态管理扩展了这一图景，但通常依赖于围绕供应商特定数据模型的外部扫描。这些工具中几乎没有能帮助合规审查人员、安全运营（SecOps）团队和平台工程师了解当前运行情况、连接对象以及如何验证这些断言。

我们专门为k8s-aibom设计了工具，以弥补这一差距。它通过实时集群观测生成BOM而非依赖工件扫描，输出符合标准的CycloneDX 1.6 ML-BOM，可与更广泛的OWASP和开源安全基金会（OpenSSF）供应链生态系统集成，而非使用供应商专有格式。它作为无特权控制器运行在任何符合规范的Kubernetes集群上，使其与现有的构建时工具和姿态管理工具形成互补关系，而非替代关系。

置信度模型：区分意图与推断

对于合规审计师和SecOps工程师而言，原始遥测数据通常是噪声。标准监控工具只能表明容器正在运行，但无法证明AI模型是否由平台工程师显式配置，还是在运行时被自主脚本动态拉取。k8s-aibom通过其确定性置信度模型解决这一歧义，将发现的资产分为不同层级：

• 已声明：由客户或开发人员在工作负载配置中显式定义（例如，显式传递容器参数如--model meta-llama/Llama-2-7b）。"已声明"的置信度检测代表明确的人类意图。

• 推断：通过控制器的模式匹配引擎对容器镜像、环境变量和执行配置进行深度检查后自主推导得出（例如，识别^vllm/.*容器签名）。

• 未解决：应用于检测到活跃AI存在但无法确定模型参数、权重和版本的工作负载。"未解决"的置信度检测会立即标记该工作负载进行针对性安全审查。

这种结构化分类法使合规审查人员能够立即区分显式工程意图与机器推断，在审计过程中建立不可动摇的信任链。

不可变性与最小权限：构建审计级安全模型

审计人员对标准可观测性遥测数据持高度怀疑态度，因为日志和指标可能被受感染节点或特权管理员修改、删除或篡改。k8s-aibom基于严格的最小权限隔离和数据不可变性，建立审计级证据链。

控制器以专用Kubernetes服务账户运行，该账户绑定到最小的标识和访问管理（IAM）工作负载标识。它是唯一被授权将BOM记录写入外部存储的标识，仅需roles/storage.objectCreator权限。

为满足最严格的审计和证据标准，Google Cloud Storage外部存储实现对对象创建强制执行DoesNotExist前置条件。一旦ML-BOM写入Cloud Storage存储桶，该对象将变为密码不可变。

它无法被受感染的集群参与者或恶意工作负载悄无声息地覆盖、修改或追溯篡改。SecOps团队可以确信呈交给监管机构的历史审计日志，是集群执行过程不可更改的完整记录。

加速治理准备：映射全球监管框架

通过自动生成标准化的CycloneDX 1.6 ML-BOM，k8s-aibom直接弥合了低层级Kubernetes运行状态与高层级治理框架之间的差距。该工具通过提供符合主要全球标准的基础实证数据，解决了阻碍GKE AI部署的关键问题：

• 欧盟AI法案：旨在帮助组织符合第12条（自动化日志记录和持续可追溯性）和第50条（AI系统透明度义务）。该工具通过自动分类服务运行时和代理堆栈，简化了合规审计期间可能需要的技术证据收集工作。

• NIST AI风险管理框架（AI RMF）：提供持续的实证资产可见性，有助于支持治理、映射、衡量和管理功能，推动合规工作流程从纯人工检查向更自动化的资产清单跟踪转变。

• ISO/IEC 42001：支持AI管理系统资产发现和追踪的合规工作，减少对人工电子表格或定期快照审计进行库存验证的依赖。

入门指南

像k8s-aibom这样的技术方案，很少能同时解决影子AI这一复杂问题，影响CISO、治理、风险与合规团队、SecOps团队、平台工程师和开发人员。

如需通过检查控制器、查看CRD定义或为开源项目k8s-aibom做贡献，欢迎访问k8s-aibom GitHub仓库。

发布分类：

• 安全与身份
• AI与机器学习
• 容器与Kubernetes