You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a maintainer rolling out OpenShell's shared Kubernetes supervisor, I need its Deployment to support the chart's OpenShift SCC compatibility overlay so that gateway topology can start under namespace-assigned user and group IDs.
Problem Statement
The supervisor Deployment introduced by #4695 hardcodes pod runAsUser, runAsGroup, and fsGroup to 65534. Unlike the gateway security contexts, these fields cannot be cleared by ci/values-openshift-scc.yaml. Under the standard restricted-v2 SCC, those IDs can fall outside the namespace's assigned ranges.
This was identified by static code review and Helm rendering; a live OpenShift rejection has not been reproduced.
Impact / Why This Matters
With supervisor_topology = "gateway", the supervisor cannot be admitted under the default restricted SCC. Helm rollout cannot complete; branches hosting sandbox sessions also cannot register them.
Acceptance Criteria
The supervisor retains its existing non-root IDs by default.
Its pod security context can be configured through Helm values.
The OpenShift overlay omits explicit user/group IDs for SCC assignment while preserving non-root and seccomp restrictions.
The topology-off chart remains unchanged.
Reproduction Steps
Render the OpenShell chart with gatewayConfig.openshell.drivers.kubernetes.supervisor_topology=gateway and the chart's ci/values-openshift-scc.yaml overlay.
Inspect the supervisor Deployment's pod security context: all three IDs remain fixed at 65534.
On an OpenShift namespace whose restricted-v2 UID/group ranges exclude 65534, deploy those values; SCC admission rejects the supervisor pod.
Deployment: OpenShift restricted-v2 SCC with namespace-assigned IDs.
Suggested UX
Keep the existing OpenShift overlay workflow; have it also clear the shared supervisor's explicit user and group IDs through a dedicated Helm security-context value.
Activity