OpenShell：沙箱身份与TLS传输解耦的凭据边界
OpenShell：沙箱身份与TLS传输解耦的凭据边界
知识点轴：sandbox-security / harness-runtime / MCP Gateway。 原始证据：NVIDIA/OpenShell PR #3110，2026-10-01合并，merge commit 021400be8af471f8669369e679de3e18cf0bd672；前置PR #2968的bootstrap合同一并查阅。保存PR说明选段而非完整53文件diff；未部署、未自行运行suite，作者测试与用户实例分开。
为什么这对用户重要
昨日sandbox-control-plane-loopback-and-reward-channel-boundaries问“沙箱可达自身控制面时到底以谁的身份访问”。这里出现一个有代码合并和测试声明的解法：传输TLS只认证网关，沙箱RPC身份交给受限JWT；不再把用户级客户端私钥放进不可信沙箱。 对任何执行外部skills/代码的agent都适用，但 OpenShell 的实现不能当作 Hermes 的现状或直接配置说明。^[raw/articles/openshell-3110-sandbox-identity-tls-2026-10-03.md]
身份/信任链
- 旧的沙箱持有网关client cert/key，将高权限私钥置于agent可接触环境；PR在Docker/Podman/Kubernetes/VM driver中改为仅投影网关CA
guest_tls_ca，用于验证对端网关证书，不是给沙箱颁发用户身份。 - 前置#2968让compute driver认证沙箱的bootstrap身份（如Kubernetes TokenReview/namespace/pod UID/owner），网关仍负责授权与JWT签发；#3110由沙箱JWT在gRPC授权边界代表沙箱自身。驱动的身份断言→网关的签发→具体RPC权限是三环，不要只查
TLS=on。 - 网关面向用户客户端的mTLS仍可配置
[openshell.gateway.mtls_auth]，由网关决定，不绑定driver；它和沙箱到网关只信任CA、JWT代表沙箱这两条链不能混为一谈。弃用的driver cert/key设置给出显式校验错误，而非默默容许继续挂载。^[raw/articles/openshell-3110-sandbox-identity-tls-2026-10-03.md]
可执行启发：隔离环境的负例矩阵（建议，未实测）
- 分别核证书/私钥是否真不在容器镜像、挂载、环境变量、日志与工作区；不只看部署清单。凭据缺席和网络隔离是两项验收。
- 造错sandbox-id、过期/错audience的JWT、跨沙箱重放及旧driver键参数；网关应拒绝且实际效果为零。确认网关实际校验的
subject/audience/expiry及driver socket信任来源，不能凭PR摘要假设覆盖上述每项。 - 对合法sandbox JWT做最小权限RPC正例和越权负例，记录哪个driver、哪个网关、版本/有效配置、trace、真实effect；MCP-Gateway-Runtime还要查调用其他REST/A2A路径是否共享同样gate。
失败模式与证据边界
取走用户私钥降低凭据外泄爆炸半径，但沙箱内仍持有自己的bearer JWT：一旦可被复制，在有效期/受众/撤销窗口内仍可能被重放，取决于真正的授权实现。恶意/被攻陷driver对bootstrap身份的断言是新边界；仅网关CA无法证明沙箱的请求主体。作者报告Rust/Python/TS测试及Python E2E 60 passed, 81 skipped，并承认其主机mise run ci曾受本机Go配置和隔离运行环境影响；不能把108绿检查或选定E2E外推所有平台、用户Mini或泄漏不可行。和vera-executable-safety-cases-and-channel-paired-verification联动：每个负例须由网关/服务侧独立证明“拒绝后零effect”。
写入记录
- 2026-10-03 09:03 CST：根据合并PR及前置bootstrap PR建立CA/沙箱JWT/用户mTLS三条身份链，形成越权与凭据暴露的隔离负例矩阵；未做本机部署。