1. Documentation
×

Security context constraints

Similar to the way that RBAC resources control user access, administrators can use security context constraints (SCCs) to control permissions for pods. These permissions determine the actions that a pod can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run.

Security context constraints allow an administrator to control the following security constraints:

  • Whether a pod can run privileged containers with the allowPrivilegedContainer flag

  • Whether a pod is constrained with the allowPrivilegeEscalation flag

  • The capabilities that a container can request

  • The use of host directories as volumes

  • The SELinux context of the container

  • The container user ID

  • The use of host namespaces and networking

  • The allocation of an FSGroup that owns the pod volumes

  • The configuration of allowable supplemental groups

  • Whether a container requires write access to its root file system

  • The usage of volume types

  • The configuration of allowable seccomp profiles

Default SCCs are created during installation and when you install some Operators or other components. As a cluster administrator, you can also create your own SCCs by using the OpenShift CLI (oc).

For information about default security context constraints, see Default security context constraints.

Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or OKD is upgraded. Additionally, the default SCC values are reset to the defaults during some cluster upgrades, which discards all customizations to those SCCs.

Instead of modifying the default SCCs, create and modify your own SCCs as needed. For detailed steps, see Creating security context constraints.

You can use the following basic SCCs:

  • restricted

  • restricted-v2

The restricted-v2 SCC is the most restrictive SCC provided by a new installation and is used by default for authenticated users. It aligns with Pod Security Admission (PSA) restrictions and improves security, as the original restricted SCC is less restrictive. It also helps transition from the original SCCs to v2 across multiple releases. Eventually, the original SCCs get deprecated. Therefore, it is recommended to use the restricted-v2 SCC.

You can examine the restricted-v2 SCC by running the following command:

$ oc describe scc restricted-v2
Example output
Name:                                           restricted-v2
Priority:                                       <none>
Access:
  Users:                                        <none>
  Groups:                                       <none>
Settings:
  Allow Privileged:                             false
  Allow Privilege Escalation:                   false
  Default Add Capabilities:                     <none>
  Required Drop Capabilities:                   ALL
  Allowed Capabilities:                         NET_BIND_SERVICE
  Allowed Seccomp Profiles:                     runtime/default
  Allowed Volume Types:                         configMap,downwardAPI,emptyDir,ephemeral,persistentVolumeClaim,projected,secret
  Allowed Flexvolumes:                          <all>
  Allowed Unsafe Sysctls:                       <none>
  Forbidden Sysctls:                            <none>
  Allow Host Network:                           false
  Allow Host Ports:                             false
  Allow Host PID:                               false
  Allow Host IPC:                               false
  Read Only Root Filesystem:                    false
  Run As User Strategy: MustRunAsRange
    UID:                                        <none>
    UID Range Min:                              <none>
    UID Range Max:                              <none>
  SELinux Context Strategy: MustRunAs
    User:                                       <none>
    Role:                                       <none>
    Type:                                       <none>
    Level:                                      <none>
  FSGroup Strategy: MustRunAs
    Ranges:                                     <none>
  Supplemental Groups Strategy: RunAsAny
    Ranges:                                     <none>

The restricted-v2 SCC explicitly denies everything except what it explicitly allows. The following settings define the allowed capabilities and security restrictions:

  • Default add capabilities: Set to <none>. It means that no capabilities are added to a pod by default.

  • Required drop capabilities: Set to ALL. This drops all the default Linux capabilities of a pod.

  • Allowed capabilities: NET_BIND_SERVICE. A pod can request this capability, but it is not added by default.

  • Allowed seccomp profiles: runtime/default.

For more information, see Managing security context constraints.