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

Role Bindings and Security Context Constraint are similar in that they both are access control mechanisms.

• Role Bindings are used to control what an OpenShift Users are allowed to do
• Security Context Constraints are used to control what pods are allowed to do

A Security Context Constraint is used to control certain things that a deployment or pod is allowed or not allowed to do, such as mounting a host volume. Typically, a Security Context Constraint (SCC) is associated with a Service Account. Check out my article Run a deployment with a Service Account and Security Context Constraint.

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

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

The --output yaml can be used to display the deployments YAML.

~]# oc get deployment my-app --output yaml
apiVersion: v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
    openshift.io/generated-by: OpenShiftNewApp
  creationTimestamp: "2021-03-23T22:06:06Z"
  generation: 1
  name: my-app
  namespace: default
  resourceVersion: "450841867"
  uid: fff40384-0b81-4016-8ff7-6a755c3d1792
spec:
  replicas: 1
  spec:
    - image: api.openshift.example.com/myapp
      imagePullPolicy: IfNotPresent
      name: my-app
      ports:
      - containerPort: 8080
        protocol: TCP
      - containerPort: 8443
        protocol: TCP
      resources: {}
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
    dnsPolicy: ClusterFirst
    restartPolicy: Always
    schedulerName: default-scheduler
    securityContext: {}
    serviceAccount: my-service-account
    serviceAccountName: my-service-account
    terminationGracePeriodSeconds: 30

The YAML output can be redirected to a file.

oc get deployment my-app --output yaml > my-app.yml

And then the oc adm policy scc-review and command with the -f or --filename option can be used to list the User, Group or Service Account and Security Context Constraints that are allowed by the deployment.

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

And the oc adm policy scc-subject-review command can be used to list the Security Context Constraints that are allowed by the deployment.

~]$ oc adm policy scc-subject-review --filename my-app.yml 
RESOURCE            ALLOWED BY         
Deployment/my-app   hostmount-anyuid

Or, this one liner can be used.

~]# oc get deployment my-app --output yaml | oc adm policy scc-review --filename - 
RESOURCE             SERVICE ACCOUNT       ALLOWED BY         
Deployment/my-app    my-service-account    hostmount-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