OpenShell

不需要。自从引入 SCC 感知的 UID 解析功能（PR #3110，以及 #4054 中的 annotation-wait 修复）之后，在大多数部署中，针对 openshell-sandbox 的 privileged SCC 授权已经不再必要。Kubernetes 驱动程序会读取命名空间的 sa.scc.uid-range 注解，并从该范围内为沙箱 Pod 分配一个 UID（例如从范围 1001150000/10000 中分配 runAsUser: 1001150000），因此该 Pod 在零特权授权的情况下即可满足默认的 restricted-v2 SCC 准入要求。

要在没有该授权的情况下部署：
1. 通过 Helm chart 并使用 values-openshift-scc.yaml overlay 安装网关，该 overlay 会将硬编码的 runAsUser/fsGroup 置空，使 restricted-v2 能够注入命名空间分配的 UID 范围。
2. 不要运行 oc adm policy add-scc-to-user privileged -z openshell-sandbox；使用 oc get scc privileged -o jsonpath='{.users}' 验证该 SA 不存在任何条目。
3. 沙箱的创建/执行/删除在 restricted-v2 下均可正常工作，进程运行在预期的 SELinux container_t 标签之下。

回退方案（可能仍需要显式授权）：依赖固定 UID 的工作负载——例如以 UID 1000 拥有文件的镜像，如 e2e/python/Dockerfile.workload——将改为在命名空间分配的 UID 下运行。对于这类情况，请显式设置 sandbox_uid，或为该特定工作负载保留 SCC 授权。请注意，较早的文档（调试技能 skills/debug-openshell-cluster/SKILL.md 和 e2e/with-kube-gateway.sh）早于该修复，仍声称需要该授权。

原因：conformance playbook 在每次 guest 启动后只等待网关连通性，但网关连通性和控制器 Deployment 可用性并不能证明 Agent Sandbox 工作负载控制器能够创建 Pod。全新启动后，控制器可能仍在恢复中——因 Kubernetes API 证书验证错误而重启，然后等待领导者选举——在调和工作负载 Pod 之前留下约 11 秒的空档。第一个 sandbox 创建随即撞上 30 秒超时，而后续场景则能通过。

临时解决方案：重新运行 CI lane。该故障是间歇性的，不做任何改动的重跑通常能通过，但这会浪费 CI 资源。

永久修复：在每次 guest 启动后添加一个有界就绪检查，在运行任何场景之前验证控制器所拥有的 Pod 创建。配置探测 Pod，使其无法实际运行或拉取镜像（使其保持门控状态），并在成功和失败两种情况下都将其清理。就绪检查失败时，跳过 conformance 并收集诊断信息：控制器状态、领导者租约、事件，以及有界的启动日志和最近的控制器日志。不要更改生产环境的 provisioning 截止期限。

本地复现方法：运行 nix run .#tmachine -- test ubuntu-k3s k3s conformance，然后比较网关连通性时间与控制器重启、领导者租约以及首个工作负载 Pod 创建的时间。