OpenShell

いいえ。SCC 対応の UID 解決が追加されて以来（PR #3110、および #4054 のアノテーション待機修正）、ほとんどのデプロイメントでは openshell-sandbox への privileged SCC 付与は不要になっています。Kubernetes ドライバーは namespace の sa.scc.uid-range アノテーションを読み取り、その範囲からサンドボックス Pod に UID を割り当てます（例: 範囲 1001150000/10000 から runAsUser: 1001150000）。そのため、Pod は privileged な付与が一切なくてもデフォルトの restricted-v2 SCC アドミッションを満たします。

付与なしでデプロイするには:
1. values-openshift-scc.yaml オーバーレイを使って Helm チャート経由でゲートウェイをインストールします。これによりハードコードされた runAsUser/fsGroup が null になり、restricted-v2 が namespace に割り当てられた UID 範囲を注入できるようになります。
2. oc adm policy add-scc-to-user privileged -z openshell-sandbox は実行しないでください。oc get scc privileged -o jsonpath='{.users}' で SA のエントリが存在しないことを確認してください。
3. サンドボックスの create/exec/delete は restricted-v2 下で正常に動作し、プロセスは期待どおり SELinux の container_t ラベルで実行されます。

フォールバック（明示的な付与が依然として必要な場合）: 固定 UID に依存するワークロード（例えば e2e/python/Dockerfile.workload のように UID 1000 としてファイルを所有するイメージ）は、代わりに namespace 割り当ての UID で実行されます。そのような場合は、sandbox_uid を明示的に設定するか、その特定のワークロードに対して SCC 付与を維持してください。なお、古いドキュメント（デバッグスキル skills/debug-openshell-cluster/SKILL.md および e2e/with-kube-gateway.sh）はこの修正より前のものであり、依然として付与が必要であると記載しています。

原因: conformance プレイブックは各ゲストブート後にゲートウェイ接続のみを待機しますが、ゲートウェイ接続とコントローラー Deployment の可用性では、Agent Sandbox ワークロードコントローラーが Pod を作成できることは証明されません。新規ブート後、コントローラーはまだ回復中の場合があります — Kubernetes API 証明書検証エラーで再起動し、続いて leader election を待機します — ワークロード Pod を reconcile するまでに約11秒のギャップが生じます。そのため、最初のサンドボックス作成は 30 秒のタイムアウトに達しますが、後続のシナリオはパスします。

回避策: CI レーンを再実行します。この失敗は断続的であり、変更なしの再実行は通常パスしますが、CI リソースを浪費します。

恒久対策: 各ゲストブート後に、シナリオを実行する前にコントローラー所有の Pod 作成を検証する、上限付き readiness チェックを追加します。probe Pod が実際に実行したりイメージをプルしたりできないように構成し(ゲート状態を維持)、成功時と失敗時の両方でクリーンアップします。readiness 失敗時は conformance をスキップし、診断情報を収集します: コントローラーの状態、leader lease、イベント、および上限付きの起動ログと最近のコントローラーログ。本番環境のプロビジョニングデッドラインは変更しないでください。

ローカルでの再現方法: nix run .#tmachine -- test ubuntu-k3s k3s conformance を実行し、ゲートウェイ接続のタイミングをコントローラーの再起動、leader lease、最初のワークロード Pod 作成と比較します。