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

Here is an illustration of how a user, group or service account get mapped to permissions. There are a number of different ways to design this, typically based on your organizations needs.

Cluster Role Binding maps a user, group or service account to a Cluster Role which will have policies that allow certain actions (such as create or delete or list) on certain resources (such as deployments, pods)

​Role Bindings maps a user, group or service account to a Role or to a Cluster Role which will have policies that allow certain actions (such as create or delete or list) on certain resources (such as deployments, pods) 

Cluster Role is often used by a number of different users, groups and service accounts in various projects, thus a Cluster Role contains the default actions (such as list, get, watch) on certain resources (such as deployments, pods) that users, groups, or service accounts are allowed to do across namespaces.

Role if isolated to a user, group or service account in a specific project, as a way of granting specific actions (such as create and delete and update) on certain resources (such as services and routes).

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

• Role Bindings are used to allow users, groups and service accounts certain actions (such as create or delete or list) on certain resources (such as deployments, pods)
• Security Context Constraints are used to control what pods are allowed to do

The oc adm policy who-can command can be used to determine if a subject (user, group, service account) has permission to perform an action (create, delete, list, get, et cetera) on resources (deployments, pods, config maps, secrets, events, et cetera). 

oc adm policy who-can <verb> <resource> --namespace <namespace>

For example.

~]$ oc adm policy who-can create secret --namespace openshift-config
Namespace: openshift-config
Verb:      create
Resource:  secrets
Users:  system:admin
        system:serviceaccount:my-project:my-service-account
Groups: my-group
        Openshift_Admin
        system:cluster-admins

Or you can describe a Role Binding to list the subject (user, group or service account) that are associated with the Role Binding. In this example, User john.doe is associated with the Role Binding named my-role-binding in namespace my-project.

~]$ oc describe rolebinding my-role-binding
Name:         my-role-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  my-role
Subjects:
  Kind  Name      Namespace
  ----  ----      ---------
  User  john.doe

Or in the OpenShift console at User Management > RoleBindings.

Notice in the above example that my-role-binding is bound to my-role. You can then describe my-role to determine the verbs (create, delete, list, get, et cetera) that john.doe is allowed on resources (deployments, pods, config maps, secrets, events, et cetera) in namespace my-project.

~]$ oc describe role my-role
Name:         my-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list watch]

Or in the OpenShift console at User Management > Roles.

Similarly, you can describe a Cluster Role Binding to list the subject (user, group or service account) that are associated with the Cluster Role Binding. In this example, Service Account my-service-account is associated with Cluster Role Binding my-cluster-role-binding in namespace my-project.

~]$ oc describe clusterrolebinding my-cluster-role-binding --namespace my-project
Name:         my-cluster-role-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  my-cluster-role
Subjects:
  Kind            Name                Namespace
  ----            ----                ---------
  ServiceAccount  my-service-account  my-project

Or in the OpenShift console at User Management > Roles.

Notice in the above example that my-cluster-role-binding is bound to my-cluster-role. You can then describe my-cluster-role to determine the verbs (create, delete, list, get, et cetera) that my-service-account is allowed on resources (deployments, pods, config maps, secrets, events, et cetera) in namespace my-project.

~]$ oc describe clusterrole my-cluster-role
Name:         my-cluster-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources   Non-Resource URLs  Resource Names  Verbs
  ---------   -----------------  --------------  -----
  configmaps  []                 []              [get list]    
  deployments []                 []              [get list]  
  pods        []                 []              [get list watch]
  replicasets []                 []              [get list]    
  rollouts    []                 []              [get list]    
  routes      []                 []              [get list]      
  secrets     []                 []              [get list]     
  services    []                 []              [get list]      

Or in the OpenShift console at User Management > Roles.

If a subject (User, Group, Service Account) does not have permission to perform an action (create, delete, list, get, et cetera) on a resource (deployments, pods, config maps, secrets, events, et cetera), you may want to Add or Remove a Role Binding from a User Group or Service Account.