Skip to content

Fix OpenShift securityContext example (podSecurityContext + fsGroup) #2869

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
pnalubandhu-a11y wants to merge 3 commits into
base: main
Choose a base branch
from
+23 −10
Open

Fix OpenShift securityContext example (podSecurityContext + fsGroup) #2869

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
41ba586
Fix OpenShift securityContext example in self-managed docs
pnalubandhu-a11y Jul 6, 2026
a7150a7
Match the exact OpenShift fsGroup error string
pnalubandhu-a11y Jul 7, 2026
e942926
Merge branch 'main' into sa/openshift-podsecuritycontext-fsgroup
mdlinville Jul 8, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 23 additions & 10 deletions platform/hosting/self-managed/operator.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,12 +63,19 @@ W&B recommends you install with the official W&B Helm chart.

#### 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.

<Note>
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`:

```bash
oc get namespace <your-namespace> -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}'
# e.g. 1000810000/10000 → use 1000810000
Comment on lines +75 to +76
```

Configure security contexts for each W&B component. For example, to configure the API component:

```yaml
Expand All @@ -77,15 +84,17 @@ api:
image:
repository: wandb/megabinary
tag: 0.74.1 # Replace with your actual version
pod:
securityContext:
fsGroup: 10001
fsGroupChangePolicy: Always
runAsGroup: 0
runAsNonRoot: true
runAsUser: 10001
seccompProfile:
type: RuntimeDefault
# 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.
podSecurityContext:
fsGroup: 1000810000 # must be within your project's UID range
fsGroupChangePolicy: Always
runAsGroup: 0
runAsNonRoot: true
runAsUser: 1000810000 # must be within your project's UID range
seccompProfile:
type: RuntimeDefault
container:
securityContext:
allowPrivilegeEscalation: false
Expand All @@ -96,6 +105,10 @@ api:
readOnlyRootFilesystem: false
```

<Note>
Both `runAsUser` **and** `fsGroup` must be set within the project's UID range. Setting only `runAsUser` leaves `fsGroup: 0`, which the `restricted-v2` SCC rejects with `fsGroup: Invalid value: []int64{0}: 0 is not an allowed group`.
</Note>

If needed, configure a custom security context for other components like `app` or `console`. For details, see [Custom security context](#custom-security-context).

## Deploy W&B Server application
Expand Down
Loading