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's include verbs, which are basically the allowed permissions. The following verbs can be used.

• create
• delete
• deletecollection
• get
• list
• patch
• update
• watch

And roles are applies to resources. For example, following are some of the more common resources.

• configmaps
• namespaces
• pods
• projects
• routes
• secrets
• services

The oc get roles command can be used to list the roles that have been created in your currently selected project.

~]$ oc get roles
NAME                  CREATED AT
my-role               2023-01-05T08:19:22Z

The oc get clusterroles command can be used to list the roles that are automatically included with OpenShift and any additional roles that you have created.

~]$ oc get clusterroles
NAME                  CREATED AT
admin                 2021-07-16T17:15:10Z
my-cluster-role       2023-01-05T08:19:22Z
basic-user            2021-07-16T17:15:10Z
cluster-admin         2021-07-16T17:15:10Z
cluster-reader        2021-07-16T17:15:10Z
cluster-status        2021-07-16T17:15:10Z
edit                  2021-07-16T17:15:10Z
self-provisioner      2021-07-16T17:15:10Z
view                  2021-07-16T17:15:10Z

Notice in this example that the following default roles exist, as well as my-cluster-role, which is a role I created using the oc create clusterole command.

• admin - Allowed to view and edit/modify all resources except for quota
• basic-user - no access to projects or resources (i'm not sure why you would ever want to apply this role to a user)
• cluster-admin - full control
• cluster-status - view basic cluster status information
• cluster-reader - allowed to view, but cannot edit or modify
• edit - allowed to view and edit certain resources such as deployments/pods/services/routes but not allowed to view or edit resources such as role bindings
• self-provisioner - user can create their own projects
• view - allowed to view resources, but cannot edit or modify resources

The oc describe clusterrole command can be used to display the permissions granted for the role.

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