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 {product-title} 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 role. |
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:
RoleBinding[admins]: Role: admin Users: [alice system:admin] Groups: [] RoleBinding[basic-user]: Role: basic-user Users: [joe] Groups: [devel]
The relationships between the the policy roles, policy bindings, users, and developers are illustrated below.
Several factors are combined to make the decision when {product-title} evaluates authorization:
In the context of authorization, both the user name and list of groups the user belongs to. |
|||||||
The action being performed. In most cases, this consists of:
|
|||||||
Bindings |
The full list of bindings. |
{product-title} evaluates authorizations using the following steps:
-
The identity and the project-scoped action is used to find all bindings that apply to the user or their groups.
-
Bindings are used to locate all the roles that apply.
-
Roles are used to find all the rules that apply.
-
The action is checked against each rule to find a match.
-
If no matching rule is found, the action is then denied by default.
There are two levels of authorization policy:
Cluster policy |
Roles and bindings that are applicable across all projects. Roles that exist in the cluster policy are considered cluster roles. Cluster bindings can only reference cluster roles. |
Local policy |
Roles and bindings that are scoped to a given project. Roles that exist only in a local policy are considered local roles. Local bindings can reference both cluster and local roles. |
This two-level hierarchy allows re-usability over multiple projects through the cluster policy while allowing customization inside of individual projects through local policies.
During evaluation, both the cluster bindings and the local bindings are used. For example:
-
Cluster-wide "allow" rules are checked.
-
Locally-bound "allow" rules are checked.
-
Deny by default.
Roles are collections of policy rules, which are sets of permitted verbs that can be performed on a set of resources. {product-title} includes a set of default roles that can be added to users and groups in the cluster policy or in a local policy.
|
Tip
|
Remember that users and groups can be associated with, or bound to, multiple roles at the same time. |
Cluster administrators can visualize these roles, including a matrix of the verbs and resources each are associated using the CLI to Additional system: roles are listed as well, which are used for various {product-title} system and component operations.
By default in a local policy, only the binding for the admin role is immediately listed when using the CLI to However, if other default roles are added to users and groups within a local policy, they become listed in the CLI output, as well.
If you find that these roles do not suit you, a cluster-admin user can create
a policyBinding object named <projectname>:default with the CLI using a
JSON file. This allows the project admin to bind users to roles that are
defined only in the <projectname> local policy.
|
Important
|
The Cluster roles are roles defined at the cluster level, but can be bound either at the cluster level or at the project level. |
From within your {product-title} project, you can determine what verbs you can perform against all namespace-scoped resources (including third-party resources). Run:
$ oc policy can-i --list --loglevel=8
The output will help you to determine what API request to make to gather the information.
To receive information back in a user-readable format, run:
$ oc policy can-i --list
The output will provide a full list.
To determine if you can perform specific verbs, run:
$ oc policy can-i <verb> <resource>
User scopes can provide more information about a given scope. For example:
$ oc policy can-i <verb> <resource> --scopes=user:info