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).

By default, if a pod 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 get securitycontextconstraints command can be used to see that the restricted Security Context Constraint has MustRunAsRange. Typically, the user running the pod ID must be between 1000910000 and 1000919999.

~]$ oc get securitycontextconstraints restricted
NAME         PRIV    CAPS         SELINUX     RUNASUSER        FSGROUP     SUPGROUP   PRIORITY     READONLYROOTFS   VOLUMES
restricted   false   <no value>   MustRunAs   MustRunAsRange   MustRunAs   RunAsAny   <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]

Let's update the deployment YAML with securityContext runAsUuser: 0 to the pod as root.

spec:
  template:
    spec:
      securityContext:
        runAsUser: 0

This should cause unable to validate against any security context constraint to be returned. Let's remove securityContext runAsUuser: 0 from the deployment YAML.

Error creating: pods "my-deployment-" is forbidden: 
unable to validate against any security context constraint: [
 spec.containers[0].securityContext.runAsUser: Invalid value: 0: must be in the ranges: [1000910000, 1000919999]
 Forbidden: not usable by user or serviceaccount, provider "anyuid"
 Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid"
 Forbidden: not usable by user or serviceaccount, provider "hostnetwork"
 Forbidden: not usable by user or serviceaccount, provider "hostaccess"
 Forbidden: not usable by user or serviceaccount, provider "nonroot"
 Forbidden: not usable by user or serviceaccount, provider "privileged"
 Forbidden: not usable by user or serviceaccount, provider "restricted"
]

The oc adm policy scc-subject-review command shows the deployment wants to use the anyuid Security Context Constraint. But by default, pods have the restricted Security Context Constraint. What to do?

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

The oc adm policy scc-review command shows that no Service Accounts are associated with the pod. This is why the pod is defaulting to the restricted Security Context Constraint.

~]$ oc get pod my-app-kf7hf --output yaml | oc adm policy scc-review -f -
RESOURCE   SERVICE ACCOUNT   ALLOWED BY

Let's create a Service Account.

~]$ oc create serviceaccount my-service-account
serviceaccount/my-service-account created

Then associate the Service Account with a Security Context Contraint (SCC). In this example, it makes sense to associate the Service Account with the anyuid Security Context Constraint since the oc adm policy scc-subject-review command returned anyuid.

~]$ oc adm policy add-scc-to-user anyuid -z my-service-account
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "my-service-account"

The oc describe clusterrolebinding command can be used to validate that the service account is bound to the anyuid Security Context Constraint.

~]$ oc describe clusterrolebinding system:openshift:scc:anyuid
Name:         system:openshift:scc:anyuid
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  system:openshift:scc:anyuid
Subjects:
  Kind            Name                Namespace
  ----            ----                ---------
  ServiceAccount  my-service-account  my-project

Then the oc set serviceaccount command can be used to have a deployment / pod run by the Service Account which will apply the Security Context Contraint (SCC) to the container / deployment / pod.

~]$ oc set serviceaccount deployment my-app my-service-account
deployment.apps/my-app serviceaccount updated

the oc set serviceaccount command will update the deployment YAML to have serviceAccount and serviceAccountName. 

spec:
  template:
    spec:
      serviceAccount: my-service-account
      serviceAccountName: my-service-account

Now the oc adm policy scc-review command shows that the pod has the Service Account and the anyuid Security Context Contraint (SCC).

~]# oc get pod my-app-mkfjk --output yaml | oc adm policy scc-review -f - 
RESOURCE            SERVICE ACCOUNT       ALLOWED BY         
Pod/my-app-mkfjk    my-service-account    anyuid

And of course the oc adm policy scc-subject-review command still shows the deployment wants to use the anyuid Security Context Constraint. But this is just nice to see, where both scc-review and scc-subject-review have the same SCC.

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

And now the oc describe pod command should show that the pod has the anyuid Security Context Contraint.

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