New “Security Context Constraints” Policies Introduced with Red Hat OpenShift 4.11
04 Jan 2023
Prepared by: Melek Sima Turunç – Sekom – AppDev & DevOps Specialist
Security Context Constraint (SCC) is a Role-based Access Control (RBAC) technology specific to Red Hat OpenShift’s pods. SCC is a component of Red Hat OpenShift that limits an existing pod to a set of resources. Its primary goal is to restrict a pod’s access to the host environment. Admins use SCCs to control pod permissions and define the conditions that must be met for a pod to be accepted into the system. These permissions include actions a pod can perform, which authorized containers the pod can run, the pod’s SELinux context, and which resources the pod can access.
Since Kubernetes 1.21, the optional PodSecurityPolicy was used, but with the release of Kubernetes 1.25, it has been completely deprecated and replaced by the Pod Security Admission control component, which is applied at the namespace level. To remain compatible with the changes made in Kubernetes, Red Hat OpenShift has updated its APIs accordingly.
For more information on which APIs have been deprecated and which versions will no longer be supported, you can refer to the Deprecated API Migration Guide on the Kubernetes website. Additionally, for information on how to update your Red Hat OpenShift operators to accommodate API changes, you can consult the Updating your operators for OpenShift when Kubernetes changes APIs document.
With the introduction of Pod Security Admission Control, namespaces and pods can now be defined with three different pod security standards: Privileged, Baseline, and Restricted. Therefore, as part of the new SCC policies (restricted-v2, nonroot-v2, and hostnetwork-v2) introduced with Red Hat OpenShift 4.11, pods that are not configured with security standards at the namespace level will not be accepted or will fail to run.
Default Security Context Constraints
| Security context constraint(SCC) | Description |
| anyuid | Provides all features of the restricted SCC, but allows users to run with any UID and any GID. 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. |
| hostaccess | 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. 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 is allocated to the namespace. 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 rooted in the cluster and must be trusted accordingly. |
| hostnetwork-v2 | Like the hostnetwork SCC, but with the following differences :
|
| node-exporter | Used for the Prometheus node exporter. 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. Like the nonroot SCC, but with the following differences: ALL capabilities are dropped from containers. |
| nonroot-v2 | 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. This is the most relaxed SCC and should be used only for cluster administration. Grant with caution. The privileged SCC allows:
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 permission 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:
In clusters that were upgraded from 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 OpenShift Container Platform 4.11 installations unless the access is explicitly granted. |
| restricted-v2 | Like the restricted SCC, but with the following differences:
This is the most restrictive SCC provided by a new installation and will be used by default for authenticated users. |
Security Context Constraints Strategies
RunAsUser
- MustRunAs – Requires a runAsUser to be configured. Uses the configured runAsUser as the default. Validates against the configured runAsUser.
- MustRunAsRange – Requires minimum and maximum values to be defined if not using pre-allocated values. Uses the minimum as the default. Validates against the entire allowable range.
- MustRunAsNonRoot – Requires that the pod be submitted with a non-zero runAsUser or have the USER directive defined in the image. No default was provided.
- RunAsAny – No default provided. Allows any runAsUser to be specified.
SELinuxContext
- MustRunAs – Requires seLinuxOptions to be configured if not using pre-allocated values. Uses seLinuxOptions as the default. Validates against seLinuxOptions
- RunAsAny – No default provided. Allows any seLinuxOptions to be specified.
SupplementalGroups
- MustRunAs – Requires at least one range to be specified if not using pre-allocated values. Uses the minimum value of the first range as the default. Validates against all ranges.
- RunAsAny – No default provided. Allows any SupplementalGroups to be specified.
FSGroup
- MustRunAs – Requires at least one range to be specified if not using pre-allocated values. Uses the minimum value of the first range as the default. Validates against the first ID in the first range
- RunAsAny – No default provided. Allows any fsGroup ID to be specified.
Kaynak: Table 1
Errors Caused by SCC and Examples from Knowledgebase:
ISSUE : Red Hat OpenShift 4.11 Workloads Failing with “Operation not permitted” Code
Solution 1 : After upgrading to Red Hat OpenShift Container Platform 4.11, issues arise in specific workloads due to SCC not functioning properly following the migration from the restricted Security Context Constraint to the restricted-v2 Security Context Constraint.
Solution 2 : In Red Hat OpenShift 4.11, processes fail when creating new pods due to the setting “allowPrivilegeEscalation: true”.
Solution 3: Source
You can stay updated on Red Hat-related news through our blog posts. Click to read our latest post on Red Hat Enterprise Linux 9.1 and 8.7 Released!
