用 k8s-aibom 盘点 Kubernetes 中真实运行的 AI 资产

预计阅读时间：10 分钟

AI 供应链管理有一个长期盲区：构建系统知道团队计划部署什么，安全平台却未必知道集群此刻真正运行着什么。开发者直接部署的 vLLM、Triton、LangChain 或向量数据库，可能没有登记到资产台账，也可能绕过只扫描制品仓库的传统工具。

开源的 k8s-aibom 试图补上运行时这一层。它以非特权 Kubernetes 控制器运行，通过观察集群 API 和容器配置识别 AI 工作负载，并生成符合 CycloneDX 1.6 的机器学习物料清单（ML-BOM）。整个过程不要求修改业务 Pod，也不需要 sidecar、eBPF 模块或特权 DaemonSet。

从集群状态生成 AI 资产清单

k8s-aibom 的发现流程可以拆成四步：

持续观察 KServe 资源以及 Deployment、StatefulSet、DaemonSet、Job 等工作负载。
检查容器镜像、环境变量和启动参数，识别 AI 技术栈。
将发现结果编译为 CycloneDX 1.6 ML-BOM。
把文档写入集群内 AIBOM 自定义资源的 status.bomDocument，并可选发送到 Google Cloud Storage 或 webhook。

它覆盖的不只是模型服务。识别范围还包括 vLLM、Triton Inference Server、TGI、Ollama 等推理运行时，LangChain、AutoGen、CrewAI 等 Agent 框架，Milvus、Qdrant、pgvector 等向量与 RAG 存储，以及分布式训练和评估任务。

这种架构的关键价值是零业务接入成本。平台团队部署一个控制器后，就能观察现有命名空间中的工作负载；应用团队不必调整 PodSpec、镜像构建过程或 CI/CD 流水线。这对治理“影子 AI”尤其重要，因为强制每个团队先完成登记，往往只会让资产继续留在治理系统之外。

Confidence Model：区分声明、推断与未知

单纯列出“这里可能有 AI”不足以支持审计。安全团队还需要知道结论来自明确配置，还是来自模式匹配。k8s-aibom 为发现结果设置了三个置信等级：

Declared：模型或组件由工作负载显式声明。例如启动参数中出现 --model meta-llama/Llama-2-7b，能直接体现工程人员的配置意图。
Inferred：控制器根据镜像名、环境变量或执行特征推断。例如镜像符合 vllm/* 特征，但没有显式模型参数。
Unresolved：已经确认存在 AI 活动，但无法确定模型名称、权重或版本。

这三个等级不能简单理解为高、中、低风险。Declared 表示证据来源明确，不代表模型本身安全；Inferred 需要结合其他遥测验证；Unresolved 则适合直接进入定向调查队列。平台可以据此制定规则，例如阻止高敏感命名空间长期存在未解决资产，而不是对所有推断结果统一告警。

可以这样检查集群中的 BOM

项目的具体 CRD 名称和安装方式可能随版本变化。安装控制器后，可以先用下面这组命令发现实际注册的 API 资源，再读取 BOM。脚本只依赖 kubectl，可直接复制执行：

#!/usr/bin/env bash
set -euo pipefail

RESOURCE="$(kubectl api-resources --verbs=list -o name | grep -E '(^|\.)aiboms?(\.|$)' | head -n 1 || true)"

if [[ -z "${RESOURCE}" ]]; then
  echo "No AIBOM API resource found. Verify that the CRD and controller are installed." >&2
  exit 1
fi

echo "Discovered resource: ${RESOURCE}"
kubectl get "${RESOURCE}" --all-namespaces

确认资源名称后，可以检查某条记录的状态。将下面的 RESOURCE、NAMESPACE 和 NAME 替换为上一条命令返回的实际值：

RESOURCE="aiboms.example.io"
NAMESPACE="default"
NAME="example-aibom"

kubectl get "${RESOURCE}" "${NAME}" \
  --namespace "${NAMESPACE}" \
  -o jsonpath='{.status.bomDocument}'
printf '\n'

如果 status.bomDocument 保存的是 JSON 对象而非字符串，可以用 jq 进行格式化和查询：

kubectl get "${RESOURCE}" "${NAME}" \
  --namespace "${NAMESPACE}" \
  -o json \
  | jq '.status.bomDocument'

还可以把未解决项接入审计任务。下面的查询假设 BOM 中的组件带有名为 confidence 的属性；字段结构应按控制器实际输出调整：

kubectl get "${RESOURCE}" "${NAME}" \
  --namespace "${NAMESPACE}" \
  -o json \
  | jq -r '
      .status.bomDocument.components[]?
      | select(any(.properties[]?; .name == "confidence" and .value == "Unresolved"))
      | [.name, (.version // "unknown")]
      | @tsv
    '

这一做法适合放进只读巡检流水线，但不应把推断结果直接当成阻断依据。更稳妥的流程是把 Unresolved 项发送到工单或 webhook，由安全人员结合网络连接、模型下载记录和工作负载负责人进行复核。

确定性输出如何服务 GitOps

k8s-aibom 把 Kubernetes 集群状态视为函数输入：相同输入产生字节级一致的 ML-BOM。这样一来，SRE 可以对 BOM 做精确 diff，只在 AI 依赖真正变化时触发告警。

实践时需要把“相同输入”的边界定义清楚。控制器版本、识别规则和配置也应纳入版本管理，否则规则升级可能改变输出，即使业务工作负载没有变化。可以将 BOM 的摘要写入审计系统：

kubectl get "${RESOURCE}" "${NAME}" \
  --namespace "${NAMESPACE}" \
  -o jsonpath='{.status.bomDocument}' \
  | sha256sum

摘要适合快速比较，但审计系统仍应保存完整 CycloneDX 文档，因为后续调查需要组件、版本、证据和置信等级等上下文。

不可变证据需要权限与存储策略共同保证

k8s-aibom 使用独立 ServiceAccount，并可通过 Workload Identity 获得最小化的云端权限。向 Cloud Storage 输出时，只授予创建对象所需的 roles/storage.objectCreator，再通过 DoesNotExist 前置条件拒绝覆盖已有对象。这能显著降低控制器凭据被滥用后篡改历史记录的风险。

不过，DoesNotExist 主要保证本次创建不会覆盖同名对象。要达到更强的监管留存要求，还应同时检查桶级删除权限、保留策略、对象锁定、管理员权限边界和审计日志。只有控制器不能覆盖对象，并不等于所有主体都无法删除或替换证据。

上线前的治理清单

k8s-aibom 更适合作为现有安全体系的补充，而不是替代品。构建期 SBOM 说明“计划交付什么”，运行时 ML-BOM 说明“现在执行什么”，云安全姿态工具则提供配置与暴露面信息。三者组合后，才能比较计划状态与实际状态。

落地时建议确认以下事项：

控制器仅获得观察工作负载和写入 AIBOM 状态所需的最小 RBAC 权限。
外部存储身份只有创建权限，没有覆盖、更新或删除历史对象的权限。
控制器版本、检测规则和输出配置全部进入 GitOps 管理。
Declared、Inferred、Unresolved 分别对应明确的复核与升级流程。
对敏感命名空间设置更严格的未解决资产时限，但避免仅凭模式匹配自动中断生产服务。
定期把运行时 BOM 与构建期 SBOM、模型注册表和网络遥测进行对账。

标准化的 CycloneDX 1.6 输出能够为 EU AI Act、NIST AI RMF 和 ISO/IEC 42001 等治理工作提供资产发现与持续记录所需的基础证据。但它提供的是可验证的数据底座，并不会自动完成合规认证。真正的价值在于把过去依赖表格和周期性访谈的 AI 盘点，变成持续、可比较、可追踪的集群事实。