Kubernetes 上的 OpenShell：平台工程师指南
内容提要
OpenShell是NVIDIA发起、现为CNCF沙箱项目的AI代理安全运行时。它在沙箱中运行代理，由外部监督器按YAML策略控制文件系统、进程、网络和凭据访问，实现按二进制、按请求的细粒度管控。其Kubernetes后端基于Agent Sandbox，代理以Pod等形式呈现，可配合RBAC和Kyverno准入策略管理镜像、权限、资源与凭据。文章还对比了OpenShell与Agent Substrate的差异及适用场景。
延伸解读
OpenShell 与 Kubernetes 原生策略的分工
OpenShell 补上了 Kubernetes 网络策略无法表达的粒度：它能按二进制和 HTTP 方法控制请求，例如允许 curl 读取 GitHub issue 但阻止其创建 issue，且无需重启即可更新规则。但文章强调，OpenShell 只检查自身依赖的 Pod 安全设置，镜像准入、资源上限、凭据注入方式等仍需平台团队通过 RBAC 和 Kyverno 等准入策略管理。两者是互补关系，而非替代。
当前限制：创建入口与扩展性
文章明确指出两个现实约束。其一，OpenShell 沙箱目前只能通过 Gateway API 创建，不能直接使用 Kubernetes API，社区已有 OpenShellSandbox CRD 和 operator 的提案但尚未落地。其二，每个代理配一个 Supervisor Pod 虽提供强隔离，但在大规模环境中可能扩展性不佳，路线图中有灵活部署选项。此外，Sandbox 没有 /scale 子资源，HPA、KEDA、VPA 无法直接针对沙箱扩缩容。
与 Agent Substrate 的选型依据
两者都运行在 Kubernetes 上，但设计目标不同。OpenShell 关注“这个代理能做什么”，适合持有真实凭据、访问生产系统、需要按请求精细控制的场景。Agent Substrate 关注“如何低成本运行大量空闲代理”，通过挂起空闲代理而非每个代理一个 Pod 来提升密度，适合每用户一个助手这类突发且多空闲的负载。文章建议根据工作负载选择，大型企业未来可能需要混合使用。
准入控制覆盖不到的场景
Kyverno 等准入策略只能看到通过 OpenShell 创建的沙箱。如果团队自己部署的 Deployment 直接调用外部 API，则不会经过网关或 Supervisor。文章提到可用基于 eBPF 的运行时监控作为补充，监视 exec、文件打开、网络和 DNS 活动，发现未经批准的代理 CLI、MCP 服务器或模型文件。这说明平台治理需要同时覆盖受管沙箱和绕过网关的工作负载。
Q&A
OpenShell 是什么？它主要解决什么问题？
OpenShell 是 NVIDIA 发起、现为 CNCF 沙箱项目的 AI 代理安全运行时。它解决的是代理作为不可信代码却持有真实凭据的问题：每个代理在沙箱中运行，由外部监督器按 YAML 策略控制文件系统、进程、网络和凭据访问，实现按二进制、按请求的细粒度管控。
OpenShell 在 Kubernetes 上如何创建和运行一个沙箱？
在 Kubernetes 上，OpenShell 网关拥有每个沙箱，并通过 Agent Sandbox 将其转为 Pod。流程包括：网关先创建两个 NetworkPolicy（工作负载 Pod 无出站、仅允许监督器入站 TCP 5500；监督器 Pod 单独策略），再创建挂起的 Sandbox 资源；Agent Sandbox 控制器创建工作负载 Pod 和 /sandbox PVC，并用调度门控暂缓；OpenShell 检查 Pod 安全设置（非 root、无额外能力、RuntimeDefault seccomp、无主机命名空间、无 ServiceAccount token 等）；随后创建监督器 Pod、Service、TLS 与引导 Secret 及短期令牌；最后移除调度门控，监督器认证并连接工作负载，沙箱运行时应用文件系统、进程、套接字和 DNS 控制后才启动代理命令。
OpenShell 的 Kubernetes 后端与原生 NetworkPolicy 相比有什么优势？
NetworkPolicy 只能表达“这个 Pod 可以访问 api.github.com 的 443 端口”，但无法表达“curl 可以读取 issues 但不能创建 issues”。OpenShell 能按调用二进制和 HTTP 请求方法进行细粒度控制，并且可以在运行中的沙箱上更新规则而无需重启。
OpenShell 和 Agent Substrate 有什么区别？分别适合什么场景？
两者都是 CNCF 沙箱项目，但设计不同：OpenShell 基于 SIG Apps 的 Agent Sandbox，每个代理一个沙箱（Sandbox、工作负载 Pod、监督器 Pod），侧重“这个代理可以做什么”，提供按请求、按二进制的策略控制，且沙箱是 Kubernetes 对象，RBAC、Kyverno、审计日志和 kubectl 都适用。Agent Substrate 有自己的调度器、控制器和运行时，以 actor（身份加快照）为单位，侧重“如何低成本运行成千上万个大多空闲的代理”，通过挂起空闲代理而非每个代理一个 Pod 来提升密度。选择建议：如果代理持有真实凭据、访问生产系统、需要按请求控制和 Kubernetes 对象策略，选 OpenShell；如果有大量突发、大多空闲的代理（如每个用户一个助手）且成本最重要，考虑 Substrate。大型企业未来可能需要混合使用。
在 OpenShell 部署中，Kyverno 能补充哪些 RBAC 做不到的控制？
RBAC 只决定谁可以对哪种资源执行哪个动词，不看请求内容，也不能添加默认值。Kyverno 在准入时检查请求内容，可覆盖：Pod 安全（禁止特权容器、要求非 root、丢弃所有能力）、限制 OpenShell RBAC 规则不得含通配符、防止工作负载 NetworkPolicy 允许直接出站、要求镜像使用不可变 sha256 摘要、为沙箱设置默认资源并限制资源上限、禁止通过 envFrom 注入 Kubernetes Secret 而应使用 OpenShell providers。演示中的七个策略均以 Enforce 模式运行，且检查请求而非发送者，因此对网关也生效。
OpenShell 沙箱的停止、启动和删除分别会发生什么？
停止会挂起 Sandbox 并移除工作负载 Pod，但保留 PVC；启动会创建新的运行时代际并重新执行 Pod 检查；删除会移除 Sandbox，并通过 owner references 清理其 Pod、Service、Secret 和 PVC，但两个命名空间级 NetworkPolicy 会保留。如果创建中途失败，驱动会回滚。
