OpenShell

아니요. SCC 인식 UID 확인 기능이 추가된 이후(PR #3110 및 #4054의 annotation-wait 수정 포함), 대부분의 배포에서 openshell-sandbox에 대한 privileged SCC 권한 부여는 더 이상 필요하지 않습니다. Kubernetes 드라이버는 네임스페이스의 sa.scc.uid-range annotation을 읽어 해당 범위에서 샌드박스 pod에 UID를 할당하므로(예: 범위 1001150000/10000에서 runAsUser: 1001150000), pod는 privileged 권한 부여 없이도 기본 restricted-v2 SCC admission을 충족합니다.

권한 부여 없이 배포하려면:
1. values-openshift-scc.yaml overlay를 사용해 Helm chart로 게이트웨이를 설치합니다. 이 overlay는 하드코딩된 runAsUser/fsGroup을 null로 설정하여 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에 의존하는 워크로드(예: e2e/python/Dockerfile.workload처럼 파일을 UID 1000으로 소유하는 이미지)는 대신 네임스페이스에 할당된 UID로 실행됩니다. 이러한 경우에는 sandbox_uid를 명시적으로 설정하거나 해당 특정 워크로드에 대해 SCC 권한 부여를 유지하세요. 이전 문서(debug skill skills/debug-openshell-cluster/SKILL.md 및 e2e/with-kube-gateway.sh)는 이 수정 이전에 작성되었으며 여전히 권한 부여가 필요하다고 기술하고 있다는 점에 유의하세요.

원인: conformance 플레이북은 각 게스트 부팅 후 게이트웨이 연결만 대기하지만, 게이트웨이 연결과 controller Deployment 가용성만으로는 Agent Sandbox 워크로드 컨트롤러가 Pod를 생성할 수 있음이 증명되지 않습니다. 새로 부팅한 후에는 컨트롤러가 아직 복구 중일 수 있습니다 — Kubernetes API 인증서 검증 오류로 재시작한 후 leader election을 대기하는 동안 — 워크로드 Pod를 reconcile하기 전까지 약 11초의 공백이 남습니다. 그러면 첫 번째 샌드박스 생성이 30초 타임아웃에 걸리는 반면 이후 시나리오들은 통과합니다.

우회 방법: CI lane을 다시 실행합니다. 이 실패는 간헐적이며 변경 없이 재실행하면 대개 통과하지만, CI 리소스를 낭비하게 됩니다.

영구 수정: 각 게스트 부팅 후 어떤 시나리오든 실행하기 전에 컨트롤러 소유 Pod 생성을 확인하는 시간 제한(bounded) readiness check를 추가합니다. probe Pod가 실제로 실행되거나 이미지를 pull할 수 없도록 구성하고(gated 상태 유지), 성공과 실패 양쪽 모두에서 정리합니다. readiness 실패 시 conformance를 건너뛰고 진단 정보를 수집합니다: 컨트롤러 상태, leader leases, 이벤트, 그리고 제한된 시작 로그와 최근 컨트롤러 로그. 프로덕션 프로비저닝 데드라인은 변경하지 마십시오.

로컬 재현 방법: nix run .#tmachine -- test ubuntu-k3s k3s conformance를 실행한 다음, 게이트웨이 연결 타이밍을 컨트롤러 재시작, leader leases, 첫 번째 워크로드 Pod 생성과 비교합니다.