Authorization policies determine whether a user is allowed to perform a given
action within a project. This allows platform administrators to
use the cluster policy to control who has
various access levels to the OpenShift Online platform itself and all projects. It also
allows developers to use local policy to
control who has access to their
projects. Note that
authorization is a separate step from authentication,
which is more about determining the identity of who is taking the action.
Authorization is managed using:
Sets of permitted verbs on a set of
objects. For example, whether something can
Collections of rules.
Users and groups can be associated
with, or bound to, multiple roles at the same time.
Associations between users and/or groups with a
Cluster administrators can visualize rules, roles, and bindings
For example, consider the following excerpt from viewing a policy, showing rule
sets for the admin and basic-user default roles:
admin Verbs Resources Resource Names Extension
[create delete get list update watch] [projects resourcegroup:exposedkube resourcegroup:exposedopenshift resourcegroup:granter secrets] 
[get list watch] [resourcegroup:allkube resourcegroup:allkube-status resourcegroup:allopenshift-status resourcegroup:policy] 
basic-user Verbs Resources Resource Names Extension
[get] [users] [~]
[list] [projectrequests] 
[list] [projects] 
[create] [subjectaccessreviews]  IsPersonalSubjectAccessReview
The following excerpt from viewing policy bindings shows the above roles bound
to various users and groups:
Users: [alice system:admin]
The relationships between the the policy roles, policy bindings, users, and
developers are illustrated below.