🔐 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
Code language: JavaScript (javascript)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 Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals