Red Hat SummitEste contenido no está disponible en el idioma seleccionado.
Chapter 10. Managing Role-based Access Control (RBAC)
10.1. Overview
You can use the CLI to view RBAC resources and the administrator CLI to manage the roles and bindings.
10.2. Viewing roles and bindings
Roles can be used to grant various levels of access both cluster-wide as well as at the project-scope. Users and groups can be associated with, or bound to, multiple roles at the same time. You can view details about the roles and their bindings using the oc describe command.
Users with the cluster-admindefault cluster role bound cluster-wide can perform any action on any resource. Users with the admin default cluster role bound locally can manage roles and bindings in that project.
Review a full list of verbs in the Evaluating Authorization section.
10.2.1. Viewing cluster roles
To view the cluster roles and their associated rule sets:
10.2.2. Viewing cluster role bindings
To view the current set of cluster role bindings, which show the users and groups that are bound to various roles:
10.2.3. Viewing local roles and bindings
All of the default cluster roles can be bound locally to users or groups.
Custom local roles can be created.
The local role bindings are also viewable.
To view the current set of local role bindings, which show the users and groups that are bound to various roles:
oc describe rolebinding.rbac
$ oc describe rolebinding.rbac
By default, the current project is used when viewing local role bindings. Alternatively, a project can be specified with the -n flag. This is useful for viewing the local role bindings of another project, if the user already has the admindefault cluster role in it.
10.3. Managing role bindings
Adding, or binding, a role to users or groups gives the user or group the relevant access granted by the role. You can add and remove roles to and from users and groups using oc adm policy commands.
When managing a user or group’s associated roles for local role bindings using the following operations, a project may be specified with the -n flag. If it is not specified, then the current project is used.
| Command | Description |
|---|---|
|
| Indicates which users can perform an action on a resource. |
|
| Binds a given role to specified users in the current project. |
|
| Removes a given role from specified users in the current project. |
|
| Removes specified users and all of their roles in the current project. |
|
| Binds a given role to specified groups in the current project. |
|
| Removes a given role from specified groups in the current project. |
|
| Removes specified groups and all of their roles in the current project. |
|
|
Can be used with |
You can also manage cluster role bindings using the following operations. The -n flag is not used for these operations because cluster role bindings use non-namespaced resources.
| Command | Description |
|---|---|
|
| Binds a given role to specified users for all projects in the cluster. |
|
| Removes a given role from specified users for all projects in the cluster. |
|
| Binds a given role to specified groups for all projects in the cluster. |
|
| Removes a given role from specified groups for all projects in the cluster. |
|
|
Can be used with |
For example, you can add the admin role to the alice user in joe-project by running:
oc adm policy add-role-to-user admin alice -n joe-project
$ oc adm policy add-role-to-user admin alice -n joe-projectYou can then view the local role bindings and verify the addition in the output:
10.4. Creating a local role
You can create a local role for a project and then bind it to a user.
To create a local role for a project, run the following command:
oc create role <name> --verb=<verb> --resource=<resource> -n <project>
$ oc create role <name> --verb=<verb> --resource=<resource> -n <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow In this command, specify: *
<name>, the local role’s name *<verb>, a comma-separated list of the verbs to apply to the role *<resource>, the resources that the role applies to *<project>, the project name+ For example, to create a local role that allows a user to view pods in the
blueproject, run the following command:+
oc create role podview --verb=get --resource=pod -n blue
$ oc create role podview --verb=get --resource=pod -n blueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - To bind the new role to a user, run the following command:
oc adm policy add-role-to-user podview user2 --role-namespace=blue -n blue
$ oc adm policy add-role-to-user podview user2 --role-namespace=blue -n blue10.5. Creating a cluster role
To create a cluster role, run the following command:
oc create clusterrole <name> --verb=<verb> --resource=<resource>
$ oc create clusterrole <name> --verb=<verb> --resource=<resource>In this command, specify:
-
<name>, the local role’s name -
<verb>, a comma-separated list of the verbs to apply to the role -
<resource>, the resources that the role applies to
For example, to create a cluster role that allows a user to view pods, run the following command:
oc create clusterrole podviewonly --verb=get --resource=pod
$ oc create clusterrole podviewonly --verb=get --resource=pod10.6. Cluster and local role bindings
A cluster role binding is a binding that exists at the cluster level. A role binding exists at the project level. The cluster role view must be bound to a user using a local role binding for that user to view the project. Create local roles only if a cluster role does not provide the set of permissions needed for a particular situation.
Some cluster role names are initially confusing. You can bind the cluster-admin to a user, using a local role binding, making it appear that this user has the privileges of a cluster administrator. This is not the case. Binding the cluster-admin to a certain project is more like a super administrator for that project, granting the permissions of the cluster role admin, plus a few additional permissions like the ability to edit rate limits. This can appear confusing especially via the web console UI, which does not list cluster role bindings that are bound to true cluster administrators. However, it does list local role bindings that you can use to locally bind cluster-admin.
10.7. Updating Policy Definitions
During a cluster upgrade, and on every restart of any master, the default cluster roles are automatically reconciled to restore any missing permissions.
If you customized default cluster roles and want to ensure a role reconciliation does not modify them:
Protect each role from reconciliation:
oc annotate clusterrole.rbac <role_name> --overwrite rbac.authorization.kubernetes.io/autoupdate=false
$ oc annotate clusterrole.rbac <role_name> --overwrite rbac.authorization.kubernetes.io/autoupdate=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow WarningYou must manually update the roles that contain this setting to include any new or required permissions after upgrading.
Generate a default bootstrap policy template file:
oc adm create-bootstrap-policy-file --filename=policy.json
$ oc adm create-bootstrap-policy-file --filename=policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe contents of the file vary based on the OpenShift Container Platform version, but the file contains only the default policies.
- Update the policy.json file to include any cluster role customizations.
Use the policy file to automatically reconcile roles and role bindings that are not reconcile protected:
oc auth reconcile -f policy.json
$ oc auth reconcile -f policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Reconcile security context constraints:
oc adm policy reconcile-sccs \ --additive-only=true \ --confirm# oc adm policy reconcile-sccs \ --additive-only=true \ --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}