零信任的下一站是进程：OpenShell supervisor 的对照与超越
内容提要
文章以NIST SP 800-207为框架，逐条对照OpenShell supervisor源码，认为其是教科书式的零信任实现，并将信任主体从用户和设备推进到进程。supervisor通过单向TLS加JWT双向认证、内核/proc身份核验、TLS拆解检查流量、凭证句柄注入、断连冻结与实例钉死恢复等机制，覆盖身份、凭证、流量和生命周期。其超出经典零信任之处在于进程级验证、隐藏网络和策略形式化验证；代价是牺牲端到端加密、审计不阻断以及代码复杂度高。
延伸解读
进程级身份：零信任粒度的一次下探
文章指出，SPIFFE/SPIRE 等方案的身份锚定在 service account，而 Agent 是动态进程树，身份随时变化。supervisor 通过 /proc 内核账本反查 socket 持有者，用 exe 路径和活 inode 哈希确认二进制身份，并沿 PPid 上溯祖先链。这相当于把零信任的“身份”从服务实例细化到进程，使策略能匹配到具体可执行文件，而非仅凭自报的进程名或参数。
拆 TLS 检查流量的收益与代价
supervisor 在沙箱内注入临时 CA，拆开 TLS 检查明文请求，再向上游重新加密。好处是能按方法、端点等 L7 粒度执行 deny-overrides 策略，并防止 HTTP 解析器被绕过。代价是端到端加密在这条路径上被牺牲，文章也承认这与 BeyondCorp 访问代理的做法一致，属于零信任架构的常见取舍，而非 OpenShell 独有偏离。
断连冻结：恢复机制也是接管防线
连接断开后，boundary 对已注册进程组发 SIGSTOP，并阻止进程自行 SIGCONT 或绕道 tgkill 解冻。只有持有有效 token 且实例 ID 与首次 attach 一致的原 supervisor 才能恢复。30 秒无人恢复则先解冻再 SIGTERM。这一设计把“防接管”和“故障恢复”合并：恢复者必须重新通过身份核验，避免任意新进程借恢复之名接管沙箱。
审计模式不等于阻断能力
文章特别提醒，audit 档只记录不拦截，被禁的 POST 在 audit 模式下会原样穿到上游。因此观察模式产生的数据不能用来宣称系统具备阻断效果。读者在评估或部署类似策略时，应区分“记录到违规”与“实际阻止违规”，避免把审计日志误读为防护生效的证据。
Q&A
OpenShell supervisor 如何实现零信任中的双向认证？
它采用单向 TLS 加 JWT 的组合：TLS 层只有服务端证书，由 driver 每次启动时生成一次性 Ed25519 CA 签发，证书有效期从 1975 到 4096 年以避开时钟依赖，加载后即删除；反向验证靠 JWT，沙箱用网关公钥验证 supervisor 令牌，并核对 runtime_generation、auth_epoch 和 supervisor 实例 ID 三个字段，防止接管和重放。
supervisor 怎么确认发起请求的进程身份，防止 Agent 伪造？
它不信任进程自报，而是通过 /proc 内核账本倒查：按连接四元组找到 socket inode，扫描 /proc/*/fd 找到持有者 PID，再 readlink /proc/<pid>/exe 获取真实路径。身份信号永久排除 cmdline（因 argv[0] 可被 execve 伪造），并计算活 inode 的 SHA256 哈希，首次记录后每次比对，不一致即拒绝。对于子进程，沿 PPid 上溯祖先链，规则匹配 exe 或任一祖先。
OpenShell 如何检查加密的 HTTPS 流量内容？
supervisor 在中间拆解 TLS：启动时生成临时 CA 并注入沙箱信任链，对客户端按主机名现签叶子证书，检查完明文后再用真实系统 CA 向上游重新加密。检查时连 HTTP 解析器都不信任，逐字节读取防走私、拒绝裸 LF、强制严格 UTF-8、多重 Host 头直接拒；策略上 deny 永远赢，audit 模式只记录不阻断。
supervisor 断连后沙箱进程会怎样？如何恢复？
连接断开时，boundary 对全部已注册进程组发 SIGSTOP 冻结，状态置为 FROZEN，并启动 30 秒恢复计时。被冻进程无法自救：自己发 SIGCONT 会被拒绝（EPERM），绕道 tgkill 也被 seccomp 拦截。只有持有有效 token 且实例 ID 与首次 attach 记录一致的原来那个 supervisor 进程，重新认证并 confirm 后才能解冻。30 秒内无人恢复，则先 SIGCONT 解冻再 SIGTERM 退出，让进程有机会清理。
OpenShell 的凭证管理如何防止 API key 泄露？
沙箱环境变量中的凭证是句柄（如 openshell:resolve:env:v<数字>_LLM_API_KEY），数字是内容指纹而非序号。真实 key 只存在于 supervisor，转发前按端点绑定注入到七个位置（header、Basic auth、query、path 段、body、WebSocket 帧、SigV4 重签）。若 key 被携带到未绑定端点，返回固定 403 字符串，不含 key 或占位符；未解析的占位符绝不转发；改写后还有后置扫描兜底；日志中敏感位置用 [CREDENTIAL] 替身。
OpenShell supervisor 相比经典零信任有哪些超越和代价？
超越有三点：信任主体从用户和设备推进到进程（验证到二进制文件加活 inode 哈希）；把网络本身藏掉（不可信侧根本没有网络）；策略变更经过形式化验证（用 SMT 求值，建模不了就返回 unsupported）。代价是：L7 检查依赖 TLS 终结，牺牲了端到端加密（但 BeyondCorp 访问代理也如此）；audit 模式的数据不能用于宣称阻断；九万二千行执法代码带来高复杂度。
