Default security context constraints

The cluster contains several default security context constraints (SCCs) as described in the table below. Additional SCCs might be installed when you install Operators or other components to Red Hat OpenShift Container Platform.

Important

Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or Red Hat OpenShift Container Platform 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.
Table 41. Default security context constraints
Security context constraint Description

anyuid

Provides all features of the restricted SCC, but allows users to run with any UID and any GID.

hostaccess

Allows access to all host namespaces but still requires pods to be run with a UID and SELinux context that are allocated to the namespace.

Warning

This SCC allows host access to namespaces, file systems, and PIDs. It should only be used by trusted pods. Grant with caution.

hostmount-anyuid

Provides all the features of the restricted SCC, but allows host mounts and running as any UID and any GID on the system.

Warning

This SCC allows host file system access as any UID, including UID 0. Grant with caution.

hostnetwork

Allows using host networking and host ports but still requires pods to be run with a UID and SELinux context that are allocated to the namespace.

Warning

If additional workloads are run on control plane hosts, use caution when providing access to hostnetwork. A workload that runs hostnetwork on a control plane host is effectively root on the cluster and must be trusted accordingly.

hostnetwork-v2

Like the hostnetwork SCC, but with the following differences:

  • ALL capabilities are dropped from containers.

  • The NET_BIND_SERVICE capability can be added explicitly.

  • seccompProfile is set to runtime/default by default.

  • allowPrivilegeEscalation must be unset or set to false in security contexts.

nested-container

Like the restricted-v2 SCC, but with the following differences:

  • seLinuxContext is set to MustRunAs and seLinuxOptions.type is container_engine_t.

  • runAsUser is set to MustRunAsRange.

  • requiredDropCapabilities is set to null.

  • userNamespaceLevel is set to RequirePodLevel, which forces pods to be in a Linux user namespace (hostUsers: false).

This SCC allows a user to run a container engine inside of an Red Hat OpenShift Container Platform pod.

node-exporter

Used for the Prometheus node exporter.

Warning

This SCC allows host file system access as any UID, including UID 0. Grant with caution.

nonroot

Provides all features of the restricted SCC, but allows users to run with any non-root UID. The user must specify the UID or it must be specified in the manifest of the container runtime.

nonroot-v2

Like the nonroot SCC, but with the following differences:

  • ALL capabilities are dropped from containers.

  • The NET_BIND_SERVICE capability can be added explicitly.

  • seccompProfile is set to runtime/default by default.

  • allowPrivilegeEscalation must be unset or set to false in security contexts.

privileged

Allows access to all privileged and host features and the ability to run as any user, any group, any FSGroup, and with any SELinux context.

Warning

This is the most relaxed SCC and should be used only for cluster administration. Grant with caution.

The privileged SCC allows:

  • Users to run privileged pods

  • Pods to mount host directories as volumes

  • Pods to run as any user

  • Pods to run with any MCS label

  • Pods to use the host’s IPC namespace

  • Pods to use the host’s PID namespace

  • Pods to use any FSGroup

  • Pods to use any supplemental group

  • Pods to use any seccomp profiles

  • Pods to request any capabilities

Note

Setting privileged: true in the pod specification does not necessarily select the privileged SCC. The SCC that has allowPrivilegedContainer: true and has the highest prioritization will be chosen if the user has the permissions to use it.

restricted

Denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace.

The restricted SCC:

  • Ensures that pods cannot run as privileged

  • Ensures that pods cannot mount host directory volumes

  • Requires that a pod is run as a user in a pre-allocated range of UIDs

  • Requires that a pod is run with a pre-allocated MCS label

  • Requires that a pod is run with a preallocated FSGroup

  • Allows pods to use any supplemental group

In clusters that were upgraded from Red Hat OpenShift Container Platform 4.10 or earlier, this SCC is available for use by any authenticated user. The restricted SCC is no longer available to users of new Red Hat OpenShift Container Platform 4.11 or later installations, unless the access is explicitly granted.

restricted-v2

Like the restricted SCC, but with the following differences:

  • ALL capabilities are dropped from containers.

  • The NET_BIND_SERVICE capability can be added explicitly.

  • seccompProfile is set to runtime/default by default.

  • allowPrivilegeEscalation must be unset or set to false in security contexts.

This SCC is used by default for authenticated users.

restricted-v3

Like the restricted-v2 SCC, but with the following differences:

  • UserNamespaceLevel is set to RequirePodLevel, which forces pods to be in a Linux user namespace (hostUsers: false).

This is the most restrictive SCC provided by a new installation and will be used by default for authenticated users.

Note

The restricted-v3 SCC is the most restrictive of the SCCs that is included by default with the system. However, you can create a custom SCC that is even more restrictive. For example, you can create an SCC that restricts readOnlyRootFilesystem to true.

↑ Up: About security context constraints | ⌂ Home: Red Hat OpenShift Container Platform | Next: Security context constraints settings →