🔐 What are Security Context Constraints (SCC) in OpenShift?
Security Context Constraints (SCC) are OpenShift’s mechanism for controlling security-sensitive aspects of how containers run in the cluster. SCCs define a set of rules that govern what actions a pod or container can perform and what privileges it can have.
They are a powerful RBAC + security enforcement layer, unique to OpenShift, built to enforce strong multi-tenancy and non-root container execution — making it more secure than vanilla Kubernetes by default.
🚧 Why SCCs Matter
By default, OpenShift enforces non-root, least privilege principles through SCCs. This prevents containers from:
- Running as the root user
- Mounting host paths
- Running privileged containers
- Escaping the container isolation
This protects the cluster from poorly configured or potentially malicious workloads.
🧱 Key Features of SCC
| SCC Attribute | What It Does |
|---|---|
runAsUser | Controls if the pod can run as root or must use a specific UID |
seLinuxContext | Defines SELinux labels that must be applied to containers |
allowPrivilegedContainer | Determines whether a pod can request privileged mode |
volumes | Limits which volume types (e.g., hostPath, PVC) a pod can mount |
allowHostNetwork | Determines if a pod can use the host’s network namespace |
allowHostPID/IPC | Controls access to the host’s PID or IPC namespaces |
readOnlyRootFilesystem | Forces the container to use a read-only root filesystem |
🧩 Default SCCs in OpenShift
| SCC Name | Use Case | Allows Running as Root? | Privileged? |
|---|---|---|---|
restricted | Default for most users | ❌ No | ❌ No |
anyuid | For workloads that require root | ✅ Yes | ❌ No |
privileged | For system-level workloads | ✅ Yes | ✅ Yes |
hostaccess | Allows host network and volumes | ✅ Yes | ❌ No |
nonroot | Must run as non-root explicitly | ❌ No | ❌ No |
baseline (v4.x+) | Common for unprivileged workloads | ❌ No | ❌ No |
You can view all SCCs in your cluster with:
oc get scc
And inspect details with:
oc describe scc restricted
🔑 Binding SCCs to Users/Service Accounts
OpenShift assigns SCCs using RBAC bindings to users, groups, or service accounts. Example:
oc adm policy add-scc-to-user anyuid -z myserviceaccount -n mynamespace
This allows your pod to run under the anyuid SCC — enabling it to run as root, if required.
⚠️ Common SCC-Related Errors
- “permission denied” when trying to bind to port < 1024 → likely due to
restrictedSCC not allowing root. - “hostPath volume mounts are not allowed” → SCC does not permit hostPath volume type.
- Container fails to start due to UID mismatch → Pod expected to run with a specific UID or non-root.
✅ Best Practices
- Stick with the
restrictedSCC whenever possible. - Avoid using
anyuidorprivilegedunless absolutely necessary. - Use custom SCCs for edge cases (e.g., to allow
hostPathvolumes or specific capabilities). - Always audit SCC use for security compliance.
I’m a DevOps/SRE/DevSecOps/Cloud Expert passionate about sharing knowledge and experiences. I am working at Cotocus. I blog tech insights at DevOps School, travel stories at Holiday Landmark, stock market tips at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at I reviewed , and SEO strategies at Wizbrand.
Do you want to learn Quantum Computing?
Please find my social handles as below;
Rajesh Kumar Personal Website
Rajesh Kumar at YOUTUBE
Rajesh Kumar at INSTAGRAM
Rajesh Kumar at X
Rajesh Kumar at FACEBOOK
Rajesh Kumar at LINKEDIN
Rajesh Kumar at PINTEREST
Rajesh Kumar at QUORA
Rajesh Kumar at WIZBRAND
