Overview of Security Context Constraints in Kubernetes/OpenShift explaining host level controls for pod privileges, kernel confinement, best practices and how SCCs complement network policies and policy as code
Security is often under-resourced in many engineering organizations. When you compare the number of application developers to dedicated security engineers, the security team is usually much smaller — and sometimes non-existent. Industry research highlights the risk: the Red Hat State of Kubernetes and Container Security Report attributes a large portion of incidents to misconfiguration (nearly 70%), with the remainder being runtime security incidents.
Security Context Constraints (SCC) are one of the platform-level controls designed to reduce these risks by limiting what pods and containers can do on the host.What SCCs control
Pod runtime privileges: whether a container can run as root or be privileged.
Host access: ability to mount host paths, use host networking, or access host PID namespaces.
Linux security mechanisms: SELinux labels, AppArmor profiles, and Linux capabilities.
SCCs are a policy mechanism focused on host- and OS-level privileges—complementary to network policy and higher-level policy engines.
How SCCs relate to other controls
Network policies (Kubernetes NetworkPolicy): control connectivity (ingress/egress) between pods, namespaces, and external endpoints.
SCCs: control privileges and capabilities at the OS/host level (privileged mode, filesystem access, capabilities, SELinux/AppArmor labels).
Open Policy Agent (OPA) and Gatekeeper: provide policy-as-code across many Kubernetes resource types and admission-time checks; they are more flexible for custom policies but operate at a different layer than SCCs.
Use these mechanisms together: network policy reduces who can reach a pod; SCCs reduce what that pod can do once running; OPA/Gatekeeper can enforce higher-level organizational rules across resources.
Kernel-level enforcement and runtime confinementSCCs may leverage native Linux kernel security modules such as SELinux and AppArmor to confine containerized processes, restrict filesystem access, and limit capabilities. These kernel primitives are powerful for reducing the attack surface of workloads.
AppArmor and SELinux-based controls are Linux-kernel specific. If you run Windows worker nodes, kernel-level modules like AppArmor will not apply the same way.
Community guidance and common misconfigurationsCommunity resources—such as the OWASP Top Ten for Kubernetes—catalog common misconfigurations and suggest secure defaults. Typical recommendations include: avoid running as root, enable read-only root filesystems, disallow privileged containers, and minimize Linux capabilities.Pod and container securityContext examplesBelow are concise examples showing where common securityContext fields belong and how they apply.Example: Pod-level runAsUser — applies to all containers in the Pod.
apiVersion: v1kind: Podmetadata: name: run-as-user-examplespec: securityContext: # Set UID for all containers in this pod (non-root recommended) runAsUser: 1000 containers: - name: app image: nginx:latest
apiVersion: v1kind: Podmetadata: name: read-only-fsspec: containers: - name: app image: nginx:latest securityContext: # Make the container filesystem read-only readOnlyRootFilesystem: true
Example: Container-level privileged flag (use with extreme caution).
apiVersion: v1kind: Podmetadata: name: privileged-podspec: containers: - name: privileged-app image: busybox:latest securityContext: # Allow the container to run in privileged mode (equivalent to Docker's --privileged) privileged: true
Running containers in privileged mode or granting excessive Linux capabilities is high risk. Avoid privileged containers unless absolutely necessary and audit any capability additions.
Best-practice checklist
Area
Recommendation
Example / Why
UID/GID
Avoid root; set runAsUser
Reduces impact of a container compromise
Filesystem
Use readOnlyRootFilesystem: true where possible
Enforces immutability and prevents on-disk tampering
Privileges
Disallow privileged: true; drop unnecessary capabilities
Minimizes host-level escalation opportunities
Kernel confinement
Use SELinux/AppArmor profiles
Strong OS-level confinement for processes
Network
Apply NetworkPolicy for ingress/egress control
Limits network-based attack paths
Policy-as-code
Use OPA/Gatekeeper for admission policies
Enforces organization-wide rules at admission time
SummarySCCs offer platform-integrated, host-level controls to reduce the attack surface of containerized workloads. Use SCCs alongside network policies and a policy-as-code tool such as OPA/Gatekeeper to create layered defenses: limit network access, minimize runtime privileges, and enforce organizational policies at admission time. These combined controls significantly reduce the likelihood and impact of misconfiguration- and runtime-related incidents.
