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

The oc describe role and oc describe clusterrole commands can be used to list the permissions of what is allowed with a Role or Cluster Role.

~]$ oc describe ClusterRole admin
Name:         admin
PolicyRule:
  Resources                                                  Non-Resource URLs  Resource Names                               Verbs
  ---------                                                  -----------------  --------------                               -----
  clusterlogforwarders.logging.openshift.io                  []                 []                                           [* create update patch delete get list watch]
  clusterloggings.logging.openshift.io                       []                 []                                           [* create update patch delete get list watch]
  serviceaccounts                                            []                 []                                           [create delete deletecollection get list patch update watch impersonate]
  buildconfigs/webhooks                                      []                 []                                           [create delete deletecollection get list patch update watch]
  buildconfigs                                               []                 []                                           [create delete deletecollection get list patch update watch]
  buildlogs                                                  []                 []                                           [create delete deletecollection get list patch update watch]

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

Create Role Binding

In this example, the oc create rolebinding command is used to create a role binding named my-basic-users that gives user john.doe the basic-user role.

~]$ oc create rolebinding my-basic-users --role basic-user --user john.doe
rolebinding.rbac.authorization.k8s.io/my-basic-users created

Or to a group.

~]$ oc create rolebinding my-basic-users --role basic-user --group my-group
rolebinding.rbac.authorization.k8s.io/my-basic-users created

Or to a service account.

~]$ oc create rolebinding my-basic-users --role basic-user --serviceaccount my-project:my-service-account
rolebinding.rbac.authorization.k8s.io/my-basic-users created

Create Cluster Role Binding

Likewise, the oc create clusterrolebinding command can be used to create a Cluster Role Binding to a user.

~]$ oc create clusterrolebinding my-basic-users --clusterrole basic-user --user john.doe
clusterrolebinding.rbac.authorization.k8s.io/my-basic-users created

Or to a group.

~]$ oc create clusterrolebinding my-basic-users --clusterrole basic-user --group my-group
rolebinding.rbac.authorization.k8s.io/my-basic-users created

Or to a service account.

~]$ oc create clusterrolebinding my-basic-users --clusterrole basic-user --serviceaccount my-project:my-service-account
rolebinding.rbac.authorization.k8s.io/my-basic-users created

Add Role Binding to User / Group / Service Account

The oc adm policy add-role-to-user command can be used to add a role binding to a user.

~]# oc adm policy add-role-to-user my-basic-users john.doe
rolebinding.rbac.authorization.k8s.io/my-basic-users added: "john.doe"

Or a group.

~]$ oc adm policy add-role-to-group my-basic-users my_group
rolebinding.rbac.authorization.k8s.io/my-basic-users added: "my_group"

Or to a service account.

~]# oc adm policy add-role-to-user my-basic-users -z my-service-account
rolebinding.rbac.authorization.k8s.io/my-basic-users added: "my-service-account"

Remove Role Binding from a User / Group / Service Account

The oc adm policy remove-role-from-user command can be used to remove a role binding from a user.

~]# oc adm policy remove-role-from-user my-basic-users john.doe
rolebinding.rbac.authorization.k8s.io/my-basic-users removed: "john.doe"

Or from a service account.

~]# oc adm policy remove-role-from-user my-basic-users -z my-service-account
rolebinding.rbac.authorization.k8s.io/my-basic-users removed: "my-service-account"

The oc adm policy remove-role-from-group command can be used to remove a role from a group.

~]$ oc adm policy remove-role-from-group my-basic-users my_group
rolebinding.rbac.authorization.k8s.io/my-basic-users removed: "my_group"

Display Role Binding Details

The oc describe rolebinding command can then be used to see that the Role Binding has been created, has the expected role (basic-user in this example) and has been applied to certain users / groups / service accounts.

~]$ oc describe rolebinding my-basic-users
Name:         my-basic-users
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  basic-user
Subjects:
  Kind            Name              Namespace
  ----            ----              ---------
  User            john.doe
  Group           my-group
  ServiceAccount  my-service-account

The oc adm policy who-can command can then be used to determine if the user or group has permission to perform an action on a resource, such as creating, updating, or deleting a config map, deployment, pod, project, secret, et cetera.

~]$ 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