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

Role Bindings, or Role Based Access Control (RBAC), contain the mapping of user, group, or service account to a role.

• Cluster Role Bindings gives a user, group or service account a certain role for every project/namespace
• Role Bindings gives a user, group or service account a certain role for a specific project/namespace

The following roles can be used.

• 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

You may want to Add or Remove a Role Binding from a User Group or Service Account.