13.3 Security Context Constraints

Overview of Security Context Constraints

Security Context Constraints (SCCs) are an OpenShift-specific mechanism that control what a pod is allowed to do at the security context level. While Kubernetes uses Pod Security Admission (and historically PodSecurityPolicies), OpenShift has SCCs as a first-class, cluster-wide resource.

SCCs define security capabilities for pods and containers, such as:

• Whether a container can run as root
• Which Linux capabilities are allowed or forbidden
• What volumes a pod can mount
• What SELinux labels are applied
• Whether host resources (PID/IPC/network namespaces, hostPath, etc.) can be used

OpenShift evaluates SCCs at pod admission time. A pod is only admitted if, given the user and service account that is creating it, at least one SCC can be applied that both:

1. Matches the pod’s requested securityContext (or can default it), and
2. Is allowed for the requesting user/service account.

Key Concepts and Terminology

SCC vs. Pod Security Context

The pod or container securityContext (in the pod spec) is what the workload asks for: user IDs, SELinux contexts, capabilities, etc.

An SCC:

• Defines the rules and defaults that apply to securityContext fields
• Can restrict requested settings (e.g., disallow privileged mode)
• Can default unset fields (e.g., assign a default runAsUser)

OpenShift admission logic takes your pod spec and an SCC, and:

• Rejects the pod if it violates the SCC
• Mutates the pod by applying defaults if needed
• Admits the pod if it complies

Built-In SCCs

Common built-in SCCs you will see on most clusters include:

• restricted
• The default, most locked-down SCC for typical workloads.
• Disallows privileged containers, host namespaces, and hostPath volumes.
• Enforces non-root UIDs and strict SELinux labeling.
• anyuid
• Allows running containers with any UID (including root), but not necessarily privileged.
• Still typically denies host networking and hostPath.
• privileged
• Broadly removes restrictions: allows privileged containers, most host namespaces, and many volume types.
• Intended for system components and trusted workloads only.
• nonroot
• Requires a non-root effective UID.
• More permissive than restricted in some ways, but still prevents root.
• hostaccess, hostmount-anyuid, hostnetwork, etc.
• Specialized SCCs that allow specific host features (host networking, hostPath mounts, etc.) for particular use cases.

Cluster administrators can create custom SCCs to fit organizational policies.

Main Fields and Controls in an SCC

Understanding the most important SCC fields helps you reason about how they impact workloads.

Privilege and Capabilities

• allowPrivilegedContainer:
• true means containers may set securityContext.privileged: true.
• This grants nearly full host access; must be tightly controlled.
• allowedCapabilities:
• List of Linux capabilities that containers are allowed to add.
• Example: ["NET_BIND_SERVICE", "SYS_PTRACE"].
• defaultAddCapabilities:
• Capabilities automatically added to containers if not specified.
• requiredDropCapabilities:
• Capabilities that must be dropped, even if a container asks for them.

These interact with pod securityContext.capabilities.add and .drop. The SCC enforces a ceiling: requested capabilities must be a subset of what the SCC allows (minus required drops).

User and Group Strategies

These strategies govern UIDs/GIDs:

• runAsUser:
• Strategies: MustRunAs, MustRunAsNonRoot, RunAsAny.
• MustRunAs requires a user ID within specified ranges.
• MustRunAsNonRoot disallows UID 0.
• RunAsAny imposes no restriction.
• fsGroup:
• Controls the group ID used for volumes.
• Strategies similar to runAsUser.
• supplementalGroups:
• Additional GIDs allowed for processes in the pod.
• seLinuxContext:
• Strategies: MustRunAs, RunAsAny, etc.
• Defines or constrains the SELinux label applied to the pod.

Together, these enforce or default identities and SELinux labels, enabling multi-tenant isolation while still allowing shared clusters.

Volume and Host Resource Controls

• volumes:
• List of allowed volume types, e.g., configMap, secret, emptyDir, persistentVolumeClaim, hostPath, etc.
• Forbidding hostPath in most SCCs is a common isolation measure.
• allowHostDirVolumePlugin (for older SCCs):
• Controls hostPath usage (superseded by volumes in newer versions).
• allowHostNetwork, allowHostPorts:
• Whether pods can use the host network namespace or host network ports.
• allowHostPID, allowHostIPC:
• Whether pods can share PID or IPC namespaces with the host.

These settings determine whether workloads can escape their container sandbox via the host filesystem or namespaces.

Other Controls

• readOnlyRootFilesystem:
• If true, forces the container root filesystem to be mounted read-only.
• allowPrivilegeEscalation / defaultAllowPrivilegeEscalation:
• Whether processes can gain more privileges than their parent process (e.g., via setuid binaries).
• allowedUnsafeSysctls / forbiddenSysctls:
• Controls which kernel parameters can be tuned per pod.

How SCCs Are Applied to Pods

User, Service Accounts, and SCCs

SCCs are granted to:

• Users
• Groups
• Service accounts

An SCC has these key association fields:

• users: list of users explicitly allowed to use this SCC.
• groups: groups that can use this SCC (e.g., system:serviceaccounts, system:authenticated).

Service accounts belong to groups such as:

• system:serviceaccounts
• system:serviceaccounts:<namespace>

When a pod is created:

1. The API server identifies the user (if created directly) and/or service account (from spec.serviceAccountName).
2. It gathers all SCCs that the user or service account is authorized to use.
3. It tries to apply each candidate SCC to the pod in priority order.

SCC Priority and Selection

SCCs have a priority field (integer). Higher values are evaluated first. The selection process is:

• Sort candidate SCCs by descending priority.
• For each SCC:
• Check if the pod’s requested securityContext is allowed by this SCC.
• If some fields are missing, attempt to fill them using the SCC’s defaults.
• If the resulting pod spec complies with this SCC, it is admitted using that SCC.
• If no SCC can satisfy the pod, admission is denied.

Important implications:

• Giving a service account access to multiple SCCs can lead to non-obvious behavior if priorities are not clearly set.
• A more permissive SCC with a higher priority may be chosen over a more restrictive SCC unless you carefully configure priorities and bindings.

Managing SCCs in Practice

Inspecting SCCs

Common commands with oc:

• List SCCs:

  oc get scc

• View a particular SCC:

  oc describe scc restricted

• View which SCC a particular pod used (from its annotations):

  oc get pod <pod-name> -o yaml | grep scc

Look for annotations such as:

• openshift.io/scc
• openshift.io/scc.uid-range

Granting an SCC to a Service Account

SCCs are cluster-scoped, but they are bound to users and groups via oc adm policy helpers or direct RBAC.

Example: allow a service account in a namespace to use the anyuid SCC:

# Create a service account
oc create sa myapp-sa -n myproject
# Add the SCC to the service account
oc adm policy add-scc-to-user anyuid -z myapp-sa -n myproject

Notes:

• -z myapp-sa refers to a service account (sa) in the given namespace.
• You can similarly use add-scc-to-group for groups.

To revoke:

oc adm policy remove-scc-from-user anyuid -z myapp-sa -n myproject

Creating a Custom SCC (Conceptually)

A typical workflow to define a custom SCC:

1. Start from a built-in SCC YAML (for example, restricted).
2. Modify specific fields:
• Allow certain capabilities.
• Adjust runAsUser ranges.
• Permit a limited set of hostPath mounts.
3. Apply it to the cluster:

   oc apply -f my-custom-scc.yaml

4. Bind it to the appropriate service accounts or groups.

When designing a custom SCC, focus on the minimal additional permissions needed for the workload to function.

Common Workload Scenarios and SCC Implications

Non-Root vs. AnyUID

Many container images are designed to run as root by default. With the default restricted SCC:

• Pods may fail if the image requires root and cannot run as an arbitrary UID.
• Common failure patterns:
• Permission denied when writing to container filesystem.
• Init scripts expecting to run as root.

Options:

• Use a base image designed for arbitrary UIDs (preferred).
• Adjust file permissions in the image to be compatible with non-root.
• As a last resort, grant anyuid to a dedicated service account and run those pods under that service account.

Privileged or Host-Accessing Workloads

Some workloads, such as:

• Device plugins
• Storage drivers
• Monitoring agents that need host-level access

may require:

• privileged SCC, or
• SCCs with allowHostPID, allowHostIPC, allowHostNetwork, or hostPath volumes.

Recommended pattern:

• Create dedicated namespaces and service accounts for such components.
• Bind them to the specialized SCC only.
• Ensure that applications in regular namespaces only use restricted or similarly tight SCCs.

Persistent Storage and SCCs

SCCs can impact volume behavior:

• Certain volume plugins may need specific SELinux labels or FSGroup ranges.
• If fsGroup strategy is too restrictive, pods may not be able to access mounted volumes.
• Incorrect SELinux strategy can cause permission denied errors on persistent volumes.

Typical mitigations:

• Ensure the SCC’s fsGroup and supplementalGroups align with storage provider recommendations.
• Use storage classes and provisioners that are compatible with the cluster’s default SCCs.

Troubleshooting SCC-Related Issues

Common symptoms of SCC misconfiguration:

• Pod admission failures with messages about SCC:
• For example: unable to validate against any security context constraint.
• Pod events indicating denied capabilities, host settings, or user IDs.
• Containers failing at runtime due to file permission issues, even when the pod is admitted.

Basic troubleshooting steps:

1. Describe the pod:

   oc describe pod <pod-name>

Look for events related to SCC or securityContext.

2. Check which SCC was used:

   oc get pod <pod-name> -o yaml | grep openshift.io/scc

3. Compare the pod’s securityContext to the selected SCC’s restrictions:

   oc describe scc <scc-name>

4. Adjust:
• The pod spec (e.g., runAsUser, capabilities, volume types), or
• The SCC grant (e.g., bind a different SCC to the service account), or
• The SCC definition (in coordination with cluster admins).

Best Practices for Using SCCs

• Least privilege by default:
• Use restricted (or an equivalent) SCC for all regular application workloads.
• Avoid anyuid and privileged unless truly necessary.
• Use dedicated service accounts:
• Do not run apps under the default service account if they need higher privileges.
• Create specific service accounts, grant them the minimal SCCs, and reference them in deployments.
• Prefer image and app adaptation over SCC relaxation:
• Modify container images to run as non-root and support arbitrary UIDs.
• Adjust filesystem permissions and entrypoints instead of broadening SCCs.
• Separate system and user workloads:
• Put system components that require elevated SCCs into separate namespaces.
• Limit who can deploy into those namespaces.
• Audit SCC usage regularly:
• Periodically list which service accounts and users have access to anyuid, privileged, and host-access SCCs.
• Tighten or remove unneeded grants.
• Document custom SCCs:
• For each custom SCC, document:
• Its intended workload(s)
• The justification for each relaxation
• Who owns and maintains it

By carefully designing and applying Security Context Constraints, OpenShift clusters can support diverse workloads—from strict multi-tenant applications to specialized platform services—while maintaining a clear, enforceable security posture at the pod level.