Kyverno之外：把K8s策略执行延伸到AI负载的运行时

2026年10月15日，CNCF博客刊发Nirmata文章，讨论一个越来越常见的缺口：Kubernetes准入控制（admission control）只能回答“这份规格看起来对不对”，回答不了“Pod跑起来之后是不是在做规格之外的事”。对自主AI智能体、行为不完全确定的LLM应用，事故往往就落在这个缺口里。

准入管不住什么

文章举例：看起来无害的镜像启动后拉二段载荷；网络权限过宽的sidecar连到未批准目的地；配置策略从未描述过的进程在运行时冒出来。准入阶段审的是声明，审不了模型在运行中临时生成的决策。

Nirmata把Kyverno捐给CNCF后，Kyverno已成为毕业项目，擅长配置安全与最佳实践自动化。Nirmata Runtime for Kyverno则是开源的运行时补充：用eBPF和Linux Security Modules（LSM），把策略执行放到内核层，而不是旁路的sidecar或用户态代理——后者可能被已沦陷的工作负载看见、拖延或绕过。

内核里同步裁决的五类行为

实现上，BPF-LSM挂到bprm_check_security、file_open等点，并用cgroup范围的eBPF管出口流量。文章归纳五类在内核内、与操作同步的行为：

• exec：按解析后的内核路径拒绝进程执行；

• open：按路径拒绝文件访问；

• network：按目的地拒绝出口；

• protocol：按真实应用协议拒绝（不只看端口，HTTPS 443上的反向壳不会因为端口“看起来对”就放行）；

• dns：观察并报告解析，默认不阻断（DNS拒绝的失败模式往往比放行更糟）。

被拒的exec在进程跑起来之前返回-EPERM；被拒连接不会建完。策略语言沿用Kyverno熟悉的CEL，RuntimePolicy用podSelector/namespaceSelector选目标。默认先以monitor模式观察（含WouldDeny反事实信号），再切enforce，避免静默开阻断。

对AI智能体意味着什么

编码智能体、MCP服务器、自治流水线步骤本质仍是Pod。文章强调：部署时能审镜像，审不了智能体还没做出的下一步。内核强制执行可作为网络策略、准入控制和应用层护栏之外的一层。

示例策略思路包括：只允许访问内部LLM网关（network/dns）；限制可启动的二进制与MCP；拒绝读取/root/.aws/credentials、kubeconfig、SSH私钥、ServiceAccount token等路径。目标是：即便提示注入或供应链问题让智能体“想越界”，执行边界也不在同一进程里，无法被它商量着关掉。

说明：文中方案为Nirmata在CNCF博客的技术介绍，落地前需按集群版本与安全基线自行评估；非CNCF对单一厂商的背书声明。

来源

[1] Extending Kubernetes policy enforcement to runtime security for AI workloads，CNCF Blog / Nirmata，2026年10月15日。

#Kubernetes #Kyverno #eBPF #运行时安全 #AI负载