Kubernetes 上的 OpenShell：平台工程师指南
内容提要
OpenShell是NVIDIA发起、现为CNCF沙箱项目的AI代理安全运行时，在沙箱中运行代理，由外部监督器按YAML策略控制文件系统、进程、网络和凭据访问，实现按二进制、按请求的细粒度管控。其Kubernetes后端基于Agent Sandbox，代理以Pod等形式呈现，可结合RBAC与Kyverno准入策略限制镜像、权限和资源。文章还对比了OpenShell与Agent Substrate的差异及适用场景。
延伸解读
OpenShell 补的是 Kubernetes 看不见的那一层
文章反复强调一个边界：NetworkPolicy 能限制 Pod 访问 api.github.com:443，却无法区分是 curl 读 issue 还是创建 issue。OpenShell 把策略检查放在每个沙箱专属的 supervisor 上，按目标、端口、调用二进制和 HTTP 方法逐请求判定，并支持运行中更新策略而无需重启。对平台团队而言，这意味着 L7 代理行为管控与 K8s 原生网络策略是互补关系，而非替代。
网关是唯一入口，但 RBAC 与准入仍需自己补齐
OpenShell 沙箱目前只能通过 Gateway API 创建，客户端不直接访问 Kubernetes API，沙箱记录才是事实来源。但文章明确指出，镜像选择、沙箱规模、凭据发放以及 OpenShell 自身 RBAC 的修改权限都留给平台团队。演示中的七条 Kyverno 策略正是用来堵住 RBAC 管不到的内容级问题，例如禁止特权容器、通配符权限、可变标签镜像和直接注入 Secret。
与 Agent Substrate 的选择取决于工作负载形态
两者都在 2026 年 9 月进入 CNCF Sandbox，但定位不同：OpenShell 解决“这个代理能做什么”，每个代理对应一个 Sandbox、一个工作负载 Pod 和一个 supervisor Pod；Substrate 解决“如何低成本运行大量闲置代理”，以 actor 快照和共享 worker 池实现挂起恢复。文章给出的判断是：代理持有真实凭据、访问生产系统、需要逐请求控制时看 OpenShell；代理数量多、突发且大多空闲、成本优先时看 Substrate。
当前限制与落地前需要留意的点
文章列出若干现实约束：每个代理一个 supervisor Pod 隔离性强，但大规模环境下可能扩展不佳，灵活部署仍在路线图中；Sandbox 没有 /scale 子资源，HPA、KEDA、VPA 无法直接以沙箱为目标；准入控制只能看到经 OpenShell 创建的代理，团队自行部署、直接调用模型服务的 Deployment 不会被覆盖，需要 eBPF 类运行时监控补充。此外，镜像签名、RuntimeClass、工作区预算和闲置清理等策略在演示中尚未包含。
Q&A
OpenShell 是什么？它主要解决什么问题？
OpenShell 是 NVIDIA 发起、现为 CNCF 沙箱项目的 AI 代理安全运行时。它解决的是 AI 代理作为不可信代码却持有真实凭据的问题：代理会执行 shell、安装包、读文件、开网络连接，OpenShell 通过沙箱运行代理，并由外部监督器按 YAML 策略控制文件系统、进程、网络和凭据访问，实现按二进制、按请求的细粒度管控。
OpenShell 在 Kubernetes 上是怎么运行的？它依赖哪些 Kubernetes 组件？
OpenShell 的 Kubernetes 后端基于 SIG Apps 的 Agent Sandbox（agents.x-k8s.io Sandbox 资源），不自带调度器。代理以 Pod、Service、PVC、Secret、NetworkPolicy 等形式呈现。网关拥有每个沙箱，Agent Sandbox 将其转为 Pod；每个代理有一个 Supervisor Pod 提供强隔离。目前沙箱只能通过 Gateway API 创建，不能直接通过 Kubernetes API 创建。
OpenShell 的 YAML 策略可以控制哪些方面？能举例说明吗？
OpenShell 在 YAML 中声明四类控制：文件系统（Landlock 限制读写路径，如 /usr、/etc 只读，仅 /sandbox、/tmp、/dev/null 可写）、进程（降权为非 root、无 capabilities、应用 seccomp）、网络（默认拒绝出站，可按二进制、主机、端口、HTTP 方法放行）、凭据（代理只看到占位符，监督器仅在允许的端点替换真实密钥）。
OpenShell 和 Kubernetes 原生 NetworkPolicy 有什么区别？
NetworkPolicy 只能表达“这个 Pod 可以访问 api.github.com 的 443 端口”，但无法表达“curl 可以读取 issues 但不能创建 issues”。OpenShell 可以做到按二进制、按请求的细粒度控制，并且可以在运行中的沙箱上更新规则而无需重启。
OpenShell 和 Agent Substrate 有什么区别？分别适合什么场景？
OpenShell 关注“这个代理可以做什么”，基于 Agent Sandbox，每个代理一个沙箱（Sandbox、工作负载 Pod、监督器 Pod），策略在监督器按请求检查，Kubernetes 对象可见，适合持有真实凭据、访问生产系统、需要按请求控制和 K8s 策略的场景。Agent Substrate 关注“如何低成本运行大量空闲代理”，有自己的调度器和 WorkerPool CRD，按 actor 快照挂起恢复，适合大量突发、多数空闲的代理（如每用户一个助手）且成本敏感的场景。大型企业未来可能需要混合使用。
在 OpenShell 部署中，Kyverno 能补充哪些 RBAC 做不到的事情？
RBAC 只能控制谁可以对什么资源执行什么动词，不看请求内容，也不能加默认值。Kyverno 在准入时检查请求内容，例如：禁止特权容器、禁止 OpenShell RBAC 规则使用通配符、禁止工作负载直接出站、要求镜像使用 sha256 摘要、为沙箱设置默认资源并限制上限、禁止通过 envFrom 注入 Kubernetes Secret 而要求使用 OpenShell providers。这些策略对包括集群管理员和网关在内的所有请求者生效。
OpenShell 沙箱的创建和运行流程是怎样的？
流程大致为：准备集群（安装支持 ingress/egress NetworkPolicy 的 CNI、Agent Sandbox 控制器和 CRD、OpenShell 网关 Helm chart）；通过 openshell sandbox create 经 mTLS 向网关发起请求；网关先创建两个 NetworkPolicy（工作负载 Pod 无出站、仅允许监督器入站 TCP 5500）；再创建 suspended 状态的 Sandbox 资源；Agent Sandbox 创建工作负载 Pod 和 PVC，调度门控暂停；OpenShell 检查 Pod 安全设置（非 root、无 capabilities、RuntimeDefault seccomp、无 host namespace、无 ServiceAccount token 等）；创建监督器 Pod、Service、TLS/引导 Secret 和短期 token；解除调度门控，监督器认证并连接工作负载，应用文件系统、进程、socket、DNS 控制后才启动代理命令。
OpenShell 沙箱的策略如何更新？停止、启动和删除时会发生什么？
策略更新通过 openshell policy update 加载新版本并等待沙箱确认，无需重启。停止会挂起 Sandbox 并移除工作负载 Pod，但保留 PVC；启动会创建新的运行时 generation 并重新执行 Pod 检查；删除会移除 Sandbox，并通过 owner references 清理其 Pod、Service、Secret 和 PVC，但两个命名空间 NetworkPolicy 会保留。如果创建中途失败，驱动会回滚。
