Fix OpenShift securityContext example (podSecurityContext + fsGroup)#2869
Fix OpenShift securityContext example (podSecurityContext + fsGroup)#2869pnalubandhu-a11y wants to merge 3 commits into
Conversation
The example puts the settings under `pod.securityContext`, but the chart reads `podSecurityContext` for the app/api pods, so runAsUser/fsGroup get ignored and the pods stay at UID 999 — which restricted-v2 rejects. Switched to `podSecurityContext`, set fsGroup too (not just the UID), and added how to find your project's UID range. Tested on OCP 4.21.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
|
Narrowing the ping. cc @wandb/delivery-tooling-team 🙂 Context: one of four small docs PRs fixing the W&B self-managed on OpenShift install guide (from a real OCP 4.21 deploy). This one fixes the securityContext example — use the top-level |
📚 Mintlify Preview Links📝 Changed (1 total)📄 Pages (1)
🤖 Generated automatically when Mintlify deployment succeeds |
🔗 Link Checker Results✅ All links are valid! No broken links were detected. Checked against: https://wb-21fd5541-sa-openshift-podsecuritycontext-fsgroup.mintlify.app |
📋 Validation of technical assertionsEvery claim below was checked against the truth on the ground using Glean (Slack, Jira, Confluence, GitHub) and Sourcegraph (the implementing Helm chart code), then put through an adversarial verification pass.
Open items — recommended next steps
Scope notes
🤖 Generated by the CoreWeave Docs Team's Validator ( |
📚 Sources and decision logFull quotes and pins behind the validation table above. Chart source (Sourcegraph,
OpenShift API (Sourcegraph, vendored copy)
Internal Slack (Glean) — #platform-delivery-tooling-team, "Thread between Flamarion and Venky" (2025-06-04)
Note on the qualifier (#6): the doc's 🤖 Generated by the CoreWeave Docs Team's Validator ( |
Review feedback: OpenShift emits Invalid value: []int64{0}, not [0], so quote
the real string that readers can grep.
There was a problem hiding this comment.
Pull request overview
This PR updates the OpenShift securityContext example in the self-managed operator documentation to ensure the Helm values actually apply to the api/app components and to prevent restricted-v2 SCC rejections.
Changes:
- Switch the example from
pod.securityContextto the chart-consumedpodSecurityContext. - Add an OpenShift command for discovering the namespace UID range and guidance for selecting values.
- Add a note explaining why both
runAsUserandfsGroupmust be set for OpenShiftrestricted-v2.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| W&B must start as the root group (`$GID=0`) for file system permissions to function properly. | ||
| </Note> | ||
|
|
||
| Find your OpenShift project's assigned UID range and use the start of that range for both `runAsUser` and `fsGroup`: |
| oc get namespace <your-namespace> -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}' | ||
| # e.g. 1000810000/10000 → use 1000810000 |
| #### Run the container as an un-privileged user | ||
|
|
||
| OpenShift and similar orchestrators often reject containers that run as root, so W&B containers must be configured to run as a non-root user that still belongs to the root group. By default, containers use a `$UID` of 999. Specify `$UID` >= 100000 and a `$GID` of 0 if your orchestrator requires the container run with a non-root user. | ||
| OpenShift and similar orchestrators often reject containers that run as root, so W&B containers must be configured to run as a non-root user that still belongs to the root group. By default, containers use a `$UID` of 999. Specify a `runAsUser` and `fsGroup` **within your project's assigned UID range** and a `$GID` of 0 if your orchestrator requires the container run with a non-root user. |
What
Fixes the OpenShift security context example on the self-managed operator page.
Why
If you copy the example as-is, the pods don't start on OpenShift:
pod.securityContext, but the chart readspodSecurityContextfor the app/api components, so runAsUser/fsGroup are ignored and the pods stay at the default UID 999.fsGroup: 0is rejected by restricted-v2:fsGroup: Invalid value: [0]: 0 is not an allowed groupChange
podSecurityContextinstead ofpod.securityContextoc get namespace ...command so people know which value to useTesting
Tried it on OCP 4.21. With the old
pod.securityContextthe app and api pods stayed at UID 999; withpodSecurityContextthey came up in the namespace range and ran fine on restricted-v2 — no custom SCC needed.