Is this page helpful?

Troubleshooting OpenShift SCC Admission Failures#

This guide covers SecurityContextConstraints (SCC) admission failures you can encounter when deploying the chart on OpenShift. By default, the chart targets the restricted-v2 SCC on every supported OpenShift release (4.11 and later) and pins admission to that profile through the openshift.io/required-scc: restricted-v2 annotation on each pod. You can override the default profile selection with the openshift.scc and openshift.sccPriority chart values. Support for the restricted-v3 SCC (introduced in OpenShift 4.20) is currently deferred pending NVIDIA GPU Operator device plugin compatibility with pod-level user namespaces (hostUsers: false).

If a pod fails to start, identify the symptom in the events stream:

oc -n <namespace> get events --sort-by='.lastTimestamp'
oc -n <namespace> describe pod <pod-name>

The events output includes the SCC validation error in FailedCreate or failedScheduling messages.

Symptom 1: Admission Validates Against restricted-v3#

Error pattern

Error creating: pods "<name>" is forbidden: unable to validate against any
security context constraint: [provider "restricted-v3":
.spec.hostUsers: Invalid value: true: must be false]

Cause

Pod admission is using restricted-v3 instead of the chart’s targeted restricted-v2. The chart deliberately does not set hostUsers: false because the NVIDIA GPU Operator device plugin does not currently support pod-level user namespaces, so restricted-v3 rejects the pod. This typically happens when a cluster-side policy or mutating webhook overwrites the chart’s openshift.io/required-scc annotation, or when openshift.annotateRequiredSCC was disabled in the values file.

Resolution

  1. Verify that the chart’s openshift.io/required-scc annotation makes it onto the pod:

    oc -n <namespace> get pod <pod-name> \
  -o jsonpath='{.metadata.annotations.openshift\.io/required-scc}{"\n"}'

    The output must be restricted-v2. If the value is restricted-v3 or empty, a cluster mutator is overriding the chart’s annotation, or openshift.annotateRequiredSCC was disabled in your values.

  2. If a mutating admission webhook is in play, work with your cluster administrator to allow restricted-v2 for the namespace, typically by labeling the namespace or carving out a webhook exclusion.

  3. Confirm openshift.annotateRequiredSCC: true (the default) in your effective values:

    helm get values <release-name> -n <namespace> --all | grep -A1 openshift

    If it is false, set it back to true and upgrade the release.

Symptom 2: Service Account Cannot Use restricted-v2#

Error pattern

Error creating: pods "<name>" is forbidden: unable to validate against any
security context constraint: [provider restricted-v2: not usable by user
or serviceaccount]

Cause

The pod’s service account does not have use permission on restricted-v2 in the namespace. By default, every authenticated user and service account on a supported OpenShift release (4.11 and later) is granted access to restricted-v2, but a cluster administrator can revoke that default grant or restrict SCC access through RBAC.

Resolution

Grant the service account access to restricted-v2 in the deployment namespace:

oc adm policy add-scc-to-user restricted-v2 -z <serviceaccount> -n <namespace>

For a chart deployment using the namespace default service account, substitute <serviceaccount> with default. If you set serviceAccount.create=true or serviceAccount.name, use that service account name instead.

Verify the grant:

oc -n <namespace> auth can-i use scc/restricted-v2 \
  --as=system:serviceaccount:<namespace>:<serviceaccount>

The output must be yes.

Symptom 3: Schema Rejects openshift.scc=restricted-v3#

Error pattern

Error: values don't meet the specifications of the schema(s) in the following
chart(s):
nim-llm:
- openshift.scc: openshift.scc must be one of the following: "auto",
  "nonroot-v2", "restricted-v2"

Cause

You tried to set openshift.scc: restricted-v3 (or any other unsupported value) through --set, a values file, or by editing values.yaml. The chart does not currently expose restricted-v3 as a selectable profile.

Resolution

Use one of the supported values: auto (default), nonroot-v2, or restricted-v2. To match the cluster’s most restrictive non-v3 profile, leave openshift.scc at auto – the chart resolves it to the first entry of openshift.sccPriority, which defaults to restricted-v2.

Symptom 4: Helm Rejects an Extra Init Container Security Context#

Error pattern

openshift.scc=restricted-v2 does not allow privileged containers
(initContainers.extraInit[0])

Other errors can mention allowPrivilegeEscalation=true, runAsUser=0, or an unsupported capabilities.add value.

Cause

When an OpenShift SCC profile is active, init containers must satisfy the same SCC baseline as workload containers. The chart merges SCC-required fields into initContainers.extraInit[*].securityContext and rejects settings that would fail OpenShift admission.

Resolution

Remove incompatible fields from initContainers.extraInit[*].securityContext. Extra init containers cannot set privileged: true, allowPrivilegeEscalation: true, runAsUser: 0, or capabilities.add values other than NET_BIND_SERVICE when openshift.scc selects restricted-v2 or nonroot-v2.