If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

A Security Context Constraint is used to control certain things, such as:

• Whether or not a pod can be run as root
• Whether or not a pod can access the host OpenShift system
• Whether or not a pod can access the host OpenShift network

Typically, a Deployment is associated with a Service Account which has a certain Security Context Constraint (SCC) so that the pod runs with a certain Security Context Constraint (SCC).

The oc get deployments command can be used to list the deployments in currently selected project.

~]# oc get deployments
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
my-app    1/1     1            1           8d

Likewise, the oc get deploymentconfigs command can be used to list the deployment configs in the currently selected project.

~]$ oc get deploymentconfigs
NAME      REVISION   DESIRED   CURRENT   TRIGGERED BY
my-app    1          1         1         config,image(my-app:latest)

By default, if a deployment is not associated with a specific Service Account that has been bound to a certain Security Context Constraint, the pod will have the restricted Security Context Constraint, which can be seen using the the oc describe pod command.

~]$ oc describe pod my-app-kf7hf
Annotations:  openshift.io/scc: restricted

The oc adm policy scc-subject-review command can be used to return the Security Context Constraint the deployment or deployment config wants to use.

~]# oc get deployment my-app --output yaml | oc adm policy scc-subject-review -f -
RESOURCE             ALLOWED BY   
Deployment/my-app    anyuid

You can then compare this to the annotation of the pod to see if the Security Context Constraints match.

~]$ oc describe pod my-app-2-1-cz4wd | grep -i scc
              openshift.io/scc: restricted

If these do not match, you may want to:

1. Create a Service Account
2. Associate the Service Account with the Security Context Constraint the deployment wants to use
3. Associated the Deployment or Deployment Config with the Service Account

After completing these steps, the oc adm policy scc-review and command should now show that the Deployment or Deployment Config is running with the Service Account and Security Context Constraint.

~]$ oc adm policy scc-review --filename my-app.yml 
RESOURCE             SERVICE ACCOUNT       ALLOWED BY         
Deployment/my-app    my-service-account    anyuid

• anyuid - Same as the "restricted" Security Context Constraint but allows a pod to be run by any User ID (UID) or Group ID (GID). Check out my article on securityContext runAsUser and runAsGroup.
• hostaccess - Allows access to all host namespaces but still requires pods to be run with a User ID (UID) and SELinux context that are allocated to the namespace. Check out my article on securityContext runAsUser and runAsGroup.
• hostmount-anyuid - Same as the "restricted" Security Context Constraint but allows host mounts and running as any User ID (UID) or Group ID (GID). Check out my article on securityContext runAsUser and runAsGroup.
• 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.
• nonroot - Same as the "restricted" Security Context Constraint but allows users to run with any non-root User ID (UID) or Group ID (GID). Check out my article on securityContext runAsUser and runAsGroup.
• privileged - 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
• restricted - Denies access to all host features and requires pods to be run with a User ID (UID), and SELinux context that are allocated to the namespace. This is the most restrictive SCC provided by a new installation and will be used by default for authenticated users.
  • Pods cannot run as privileged
  • Pods cannot mount host directory volumes (see Mount a local directory in a deployment and hostPath volumes are not allowed to be used)
  • Requires that a pod is run as a user in a pre-allocated range of User IDs (UIDs).
  • Requires that a pod is run with a pre-allocated MCS label
  • Allows pods to use any FSGroup
  • Allows pods to use any supplemental group