将Kubernetes策略执行扩展至AI工作负载的运行时安全
内容提要
Nirmata推出开源项目Runtime for Kyverno，基于eBPF和Linux安全模块，将策略执行从Kubernetes准入控制扩展至内核级运行时，可同步拦截exec、文件访问、网络出口和协议，默认监控模式，并复用Kyverno的CEL策略语言与OpenReports。该方案适用于行为由模型动态决定的AI代理，能限制其访问的模型端点、可执行文件和MCP服务器，弥补准入控制无法覆盖运行时行为的缺口。
延伸解读
准入控制与运行时安全的本质差异
文章指出，Kubernetes准入控制只能回答“这个spec看起来对吗”，无法回答Pod运行后“工作负载是否在做它该做的事”。对于行为由模型动态决定的AI代理，这一缺口尤为关键。Nirmata Runtime for Kyverno通过eBPF和LSM将策略执行下沉到内核，在系统调用层面同步拦截exec、文件访问、网络出口和协议，弥补了准入控制无法覆盖运行时行为的不足。
内核级执行的优势与实现机制
文章强调，任何与工作负载并行的控制（如sidecar、代理）都可能被工作负载自身 compromise 看到、拖延或绕过。而Nirmata Runtime将BPF-LSM程序直接附加到bprm_check_security和file_open，并用cgroup范围的eBPF程序控制出口路径，实现“工作负载没有投票权”的强制力。被阻止的exec在进程运行前返回-EPERM，被阻止的连接永远不会完成，决策与执行之间没有可竞态窗口。
策略语言与运维体验的延续性
Nirmata Runtime复用Kyverno的CEL策略语言和OpenReports报告API，RuntimePolicy通过podSelector/namespaceSelector定位工作负载，并支持从ConfigMap或HTTP源动态拉取值。所有策略默认以监控模式发布，提供WouldDeny反事实信号，避免静默进入阻断模式。这种设计让准入与运行时成为连续的策略故事，而非两套无关工具，降低了运维复杂度。
针对AI代理的运行时控制实践
文章以agent pod为例，展示如何通过RuntimePolicy限制其只能访问内部LLM网关，并禁止读取凭证文件。network和protocol行为使用“*”哨兵值，要求连接同时通过地址和协议检查；open行为则直接列出敏感路径。这能应对提示注入、供应链依赖或工具调用失控等风险，且无需代理或独立控制平面。监控模式下，monitorFilter可用CEL过滤噪声，让报告直接指出代理CLI或推理服务器的出现。
Q&A
Nirmata Runtime for Kyverno 是什么？它解决了什么问题？
Nirmata Runtime for Kyverno 是 Nirmata 推出的开源项目，使用 eBPF 和 Linux 安全模块（LSM）将策略执行从 Kubernetes 准入控制扩展到内核级运行时。它解决了准入控制无法覆盖运行时行为的问题，例如容器启动后拉取二次载荷、sidecar 与未授权目的地通信、或执行未预期的进程。
Nirmata Runtime 如何在内核中执行策略？它拦截哪些行为？
Nirmata Runtime 将 BPF-LSM 程序附加到 bprm_check_security 和 file_open，并将 cgroup 范围的 eBPF 程序附加到出口路径，按 Pod 执行。它同步拦截五种行为：exec（按解析的内核路径拒绝进程执行）、open（按解析的内核路径拒绝文件访问）、network（按目的地拒绝出口）、protocol（按实际应用协议拒绝，独立于端口）、dns（观察并报告解析，不阻断）。
Nirmata Runtime 如何复用 Kyverno 的策略概念？
它使用与 Kyverno 准入策略相同的 CEL 策略语言。RuntimePolicy 通过 podSelector/namespaceSelector 定位工作负载，并按行为表达允许/拒绝逻辑，支持从 ConfigMap 或 HTTP 源拉取实时值的表达式。策略默认以监控模式发布，可先观察 WouldDeny 反事实信号再切换为执行模式。它还使用相同的报告 API（OpenReports），并计划添加类似 Kyverno 的细粒度例外。
对于 AI 代理工作负载，Nirmata Runtime 能提供哪些具体控制？
对于 AI 代理工作负载，Nirmata Runtime 可以：限制代理允许通信的模型提供商和端点（通过 dns 和 network 行为报告或阻断未批准列表外的解析和出口）；限制代理可以启动的二进制文件和 MCP 服务器（通过 exec 允许列表关闭任意工具调用）；检测镜像中已存在的代理 CLI 和 SDK，以及工作负载读取的模型文件和 MCP 配置。
Nirmata Runtime 如何提供可观测性并归因策略决策？
当 Nirmata Runtime 拒绝操作时，内核将决策编码在 map 键中，用户空间根据观察到的目标重新评估编译后的策略，以归因到确切的策略。无法归因的事件不会被静默丢弃，而是计数并记录为缺口（events_dropped_total{reason="unattributed_kernel_deny"}）。发现结果以标准 Kubernetes OpenReports 对象呈现，无需专有仪表板。
monitorFilter 在 Nirmata Runtime 中起什么作用？
monitorFilter 是一个按观察执行的 CEL 谓词，在写入发现结果之前运行，用于过滤噪音。例如，在监控模式下观察 exec 时，它会流式传输 Pod 运行的每个进程，但 monitorFilter 可以只保留代理 CLI 或本地推理服务器的调用，避免将 sh、grep 等正常容器 argv 写入 Report。
