Configuring security context constraints

With security context constraints (SCCs), we can control the actions and access that pods within your Red Hat OpenShift on IBM Cloud cluster can perform. For more information about SCCs, see the OpenShift docs.

Why do I set security context constraints?
As a cluster admin, we want to control what happens in the cluster, especially actions that affect the cluster's security or readiness. Security context constraints can help you control what actions and access the pods in your container have, such as the usage of privileged containers, root namespaces, host networking and ports, volume types, host file systems, Linux permissions such as read-only or group IDs, and more.

Can I also add users or system groups to SCCs?
For user access to the cluster resources, do not use SCCs. Instead, see Assigning cluster access to set IBM Cloud IAM and infrastructure permissions.

For system groups such as system:authenticated, these groups already are assigned to SCCs. We can see which groups are assigned to an SCC by describing the SCC. If you change the SCC that a system group is assigned to, default components that belong to the system group might experience errors due to the change in permissions.

Are any SCCs set by default?
By default, Red Hat OpenShift on IBM Cloud clusters include a standard set of OpenShift SCCs. Additionally, clusters have IBM SCCs that closely resemble the Kubernetes pod security policies of community Kubernetes clusters in IBM Cloud Kubernetes Service. These IBM SCCs are included for improved portability with IBM Cloud Private packages such as Cloud Paks.

What SCCs are applied to my resources by default?
If you do not specify a security context, the OpenShift restricted security context constraint is applied by default. To check a pod's security context, describe the pod and look for the SCC annotation, such as in the following example.

oc describe pod <pod_name>

Name:               <pod_name>
Namespace:          <project_name>
...
Annotations:        openshift.io/...
           openshift.io/scc=restricted
...

Can I use Kubernetes pod security policies instead?
No. Kubernetes pod security policies (PSPs) are originally based on OpenShift SCCs. However, OpenShift supports only SCCs, not PSPs.

The default OpenShift SCCs are stricter than the default PSPs in community Kubernetes clusters. As such, app deployments that run in community Kubernetes clusters might need to be modified to run in OpenShift.

Customizing security context constraints

To create, edit, list, delete, and otherwise manage security context constraints, see the OpenShift docs. We can also add users or groups to the default security context constraints.

Make sure that you use the oc CLI or kubectl version 1.12 CLI to interact with these resources, such as oc get scc. The kubectl CLI version 1.11 CLI has a bug that yields an error when you run commands against OpenShift -specific resources, such as kubectl get scc.

Default OpenShift security context constraints

Red Hat OpenShift on IBM Cloud clusters come with the following security context constraints by default.

Do not edit existing OpenShift or IBM SCCs settings, except for priority, users, or groups fields.

SCC name Description

anyuid Denies access similar to the restricted SCC, but allows users to run with any UID and any GID.

hostaccess Allows access to all host namespaces, but still requires that pods are run with a UID and SELinux context that are allocated to the namespace.
Grant this SCC for only trusted pods that require host access to namespaces, file systems, and process IDs.

hostmount-anyuid Denies access similar to the restricted SCC, but allows host mounts and any UID by a pod. This SCC is primarily used by the persistent volume recycler.
Grant this SCC for only pods that require host file system access as any UID, including UID 0.

hostnetwork Allows the usage of host networking and host ports, but still requires that pods are run with a UID and SELinux context that are allocated to the namespace.
Grant this SCC for only pods that require host network access.

node-exporter Gives the appropriate access for the built-in Prometheus node exporter.

nonroot Denies access similar to the restricted SCC, but allows users to run with any non-root UID. Either the user or the manifest of the container runtime must specify the UID.

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.
Grant this SCC for only cluster administration that requires the most access possible.

restricted Denies access to all host features and requires that pods are run with a UID and SELinux context that are allocated to the namespace. This is the most restrictive SCC, and it is used by default for authenticated users.

SCC name	Description
anyuid	Denies access similar to the restricted SCC, but allows users to run with any UID and any GID.
hostaccess	Allows access to all host namespaces, but still requires that pods are run with a UID and SELinux context that are allocated to the namespace. Grant this SCC for only trusted pods that require host access to namespaces, file systems, and process IDs.
hostmount-anyuid	Denies access similar to the restricted SCC, but allows host mounts and any UID by a pod. This SCC is primarily used by the persistent volume recycler. Grant this SCC for only pods that require host file system access as any UID, including UID 0.
hostnetwork	Allows the usage of host networking and host ports, but still requires that pods are run with a UID and SELinux context that are allocated to the namespace. Grant this SCC for only pods that require host network access.
node-exporter	Gives the appropriate access for the built-in Prometheus node exporter.
nonroot	Denies access similar to the restricted SCC, but allows users to run with any non-root UID. Either the user or the manifest of the container runtime must specify the UID.
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. Grant this SCC for only cluster administration that requires the most access possible.
restricted	Denies access to all host features and requires that pods are run with a UID and SELinux context that are allocated to the namespace. This is the most restrictive SCC, and it is used by default for authenticated users.

Default IBM security context constraints

Red Hat OpenShift on IBM Cloud clusters come with the following IBM security context constraints by default.

Do not edit existing OpenShift or IBM SCCs settings, except for priority, users, or groups fields.

SCC name Description

ibm-anyuid-hostaccess-scc Allows pods to run with any UID and GID, any volume, and full access to the host.
Grant this SCC for only pods that require full access to the host and network.

ibm-anyuid-hostpath-scc Allows pods to run with any UID and GID and any volume, including the host path.
Grant this SCC for only pods that require access to hostPath volumes.

ibm-anyuid-scc Allows pods to run with any UID and GID, but prevents access to the host.

ibm-privileged-scc Grants access to all privileged host features, and allows a pod to run with any UID and GID and any volume.
Grant this SCC for only cluster administration that requires the most access possible.

ibm-restricted-scc Denies access to all host features and requires that pods are run with a UID and SELinux context that are allocated to the namespace. This SCC is the most restrictive IBM SCC.

SCC name	Description
ibm-anyuid-hostaccess-scc	Allows pods to run with any UID and GID, any volume, and full access to the host. Grant this SCC for only pods that require full access to the host and network.
ibm-anyuid-hostpath-scc	Allows pods to run with any UID and GID and any volume, including the host path. Grant this SCC for only pods that require access to hostPath volumes.
ibm-anyuid-scc	Allows pods to run with any UID and GID, but prevents access to the host.
ibm-privileged-scc	Grants access to all privileged host features, and allows a pod to run with any UID and GID and any volume. Grant this SCC for only cluster administration that requires the most access possible.
ibm-restricted-scc	Denies access to all host features and requires that pods are run with a UID and SELinux context that are allocated to the namespace. This SCC is the most restrictive IBM SCC.