Fix OpenShift securityContext example (podSecurityContext + fsGroup) - #2869
pnalubandhu-a11y wants to merge 4 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. Preview: https://wb-21fd5541-sa-openshift-podsecuritycontext-fsgroup.mintlify.site |
📋 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.
Readability impactWord-weighted Flesch-Kincaid grade change across 1 changed page: +0.0 (unchanged). Lower Flesch-Kincaid grade and higher reading ease both mean easier to read. This check is informational and never blocks a PR. Human readability
AI agent comprehensionRated 0-3 (higher is easier for an agent to parse and act on).
Curated-docs baseline median FK grade by type: conceptual 10.5, procedural 8.8, reference 9.4. |
| #### 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. |
There was a problem hiding this comment.
| 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. | |
| 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 to run with a non-root user. |
There was a problem hiding this comment.
🟡 Changes recommended
The security-group range guidance and conflicting later documentation must be resolved.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 2
- Review effort level: Lite
| Find your OpenShift project's assigned UID range and use the start of that range for both `runAsUser` and `fsGroup`: | ||
|
|
||
| ```bash | ||
| oc get namespace <your-namespace> -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}' | ||
| # e.g. 1000810000/10000 → use 1000810000 |
| # Use the top-level `podSecurityContext` key. The nested `pod.securityContext` | ||
| # is NOT applied to runAsUser/fsGroup for these components, so pods would stay | ||
| # at the default UID 999 and be rejected by the `restricted-v2` SCC. |
|
Hi @pnalubandhu-a11y , apologies that this has taken so long to review, but I'm not sure how best to address CoPilot's open feedback. Please resurrect this PR in |
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.