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

The oc get deployments command can be used to list the deployments in a namespace.

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

The oc edit deployment command can be used to edit the deployments YAML. In this example, the container in the deployment is updated to be runAsUser 0 (root) and runAsGroup 0 (root) and the /var/data Persistent Volume Claim will be owned by fsGroup (file system group) 0 (root).

The securityContext is defined before containers so that runAsUser, runAsGroup and fsGroups are applied to all containers

spec:
  template:
    spec:
      securityContext:
        runAsUser: 0
        runAsGroup: 0
        fsGroup: 0
      containers:
      - name: myapp
        image: api.openshift.example.com/myapp
        volumeMounts:
        - mountPath: /var/data
          name: my-volume
      volumes:
      - name: my-volume
        persistentVolumeClaim:
          claimName: my-persistent-volume-claim

Then the oc adm policy scc-subject-review and oc adm policy scc-subject-review commands can be used list the Security Context Constraints that are allowed by the deployment.

AVOID TROUBLE

The non-root Security Context Constraint (SCC) restricts the pod from being run as root, meaning you wouldn't be able to run the pod with runAsUser 0 (root) or runAsGroup 0 (root)

~]# oc get deployment my-app --output yaml | oc adm policy scc-review --filename - 
RESOURCE             SERVICE ACCOUNT       ALLOWED BY         
Deployment/my-app    my-service-account    non-root

• anyuid - Same as the "restricted" Security Context Constraint but allows a pod to be run by any User ID (UID) or Group ID (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.
• hostmount-anyuid - Same as the "restricted" Security Context Constraint but allows host mounts and running as any User ID (UID) or Group ID (GID).
• hostnetwork - Allows using host networking and host ports but still requires pods to be run with a User ID (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 UID. The user must specify the UID or it must be specified in the manifest of the container runtime.
• 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 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.
  • 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 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

runAsUser 0 (root)

Often, if you try to run a pod as root, unable to validate against any security context constraint will be returned. 

Error creating: pods "my-deployment-" is forbidden: 
unable to validate against any security context constraint: [
 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"
]

This occurs when the Security Context Contraint does not allow the pod to be run as root.

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

You can create a Service Account.

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

And then associate the Service Account with the privileged Security Context Constraint.

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

And then edit the deployment with serviceAccountName and serviceAccount and runAsUser (and optionally runAsGroup and fsGroup).

spec:
  template:
    spec:
      containers:
      - name: myapp
        image: api.openshift.example.com/myapp
        volumeMounts:
        - mountPath: /var/data
          name: my-volume
      serviceAccount: my-service-account
      serviceAccountName: my-service-account
      securityContext:
        runAsUser: 0
        runAsGroup: 0
        fsGroup: 0      
      volumes:
      - name: my-volume
        persistentVolumeClaim:
          claimName: my-persistent-volume-claim

Now the deployment should have the privileged Security Context Constraint.

~]# oc get deployment my-app --output yaml --namespace my-project | oc adm policy scc-subject-review --filename -
RESOURCE            ALLOWED BY         
Deployment/my-app   privileged

And the whoami command in the container should show that the pod is being run as root.

~]# oc exec pod/my-pod-7stht -- whoami
root