Privileged SCC Explained¶

Introduction¶

Security Context Constraints control what pods are allowed to do in OpenShift. SCC failures usually mention forbidden securityContext fields, UID ranges, host access, or privilege requests.

Why This Matters¶

OpenShift adds security defaults such as SCCs, project isolation, and integrated OAuth/RBAC behavior. These protections are useful only when permissions are granted narrowly and verified.

Step-by-Step Configuration¶

oc describe pod web-7c9d7f6f8b-jx4mk -n app

oc get scc restricted-v2 -o yaml

oc adm policy add-scc-to-user anyuid -z web-sa -n app

oc auth can-i use scc/anyuid --as=system:serviceaccount:app:web-sa

Example output:

clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "web-sa"
yes

Example YAML¶

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  serviceAccountName: web-sa
  containers:
    - name: web
      image: registry.access.redhat.com/ubi9/httpd-24

Verification¶

oc auth can-i use scc/anyuid --as=system:serviceaccount:app:web-sa

oc describe pod -l app=web -n app

Security Best Practices¶

Grant the smallest role or SCC that works, prefer service-account-specific access, keep secrets out of Git, and verify permissions with oc auth can-i.

Common Mistakes¶

• Granting privileged SCC when anyuid or a tighter custom SCC is enough.
• Granting SCC to a user instead of the service account used by the pod.
• Ignoring OpenShift default random UID behavior.

Troubleshooting¶

Compare the failing user or service account with the role binding, SCC admission error, project quota, or OAuth status shown in OpenShift events.

Related Guides¶

• Openshift Security Context Constraints Explained
• Openshift RBAC Security Explained
• Openshift Security Checklist

Summary¶

Privileged SCC Explained is safest when permissions are explicit, namespace-scoped where possible, and validated from the same identity that runs the workload.