Defining and Applying Permissions using RBAC

[wangglbj]

Defining and Applying Permissions using RBAC Role-based Access Control (RBAC) Role-based access control (RBAC) is a technique for managing access to resources in a computer system. In Red Hat OpenShift, RBAC determines if a user can perform certain actions within the cluster or project. There are two types of roles that can be used depending on the user's level of responsibility: cluster and local.

Note: Authorization is a separate step from authentication.

Authorization Process

The authorization process is managed by rules, roles, and bindings.

RBAC Object | Description -- | -- Rule | Allowed actions for objects or groups of objects. Role | Sets of rules. Users and groups can be associated with multiple roles. Binding | Assignment of users or groups to a role.

**RBAC Scope** Red Hat OpenShift Container Platform (RHOCP) defines two groups of roles and bindings depending on the user's scope and responsibility: cluster roles and local roles. Role Level | Description -- | -- Cluster Role | Users or groups with this role level can manage the OpenShift cluster. Local Role | Users or groups with this role level can only manage elements at a project level. _Note: Cluster role bindings take precedence over local role bindings._ **Managing RBAC Using the CLI** ``` Cluster administrators can use the oc adm policy command to both add and remove cluster roles and namespace roles. To add a cluster role to a user, use the add-cluster-role-to-user subcommand: [user@host ~]$ oc adm policy add-cluster-role-to-user cluster-role username For example, to change a regular user to a cluster administrator, use the following command: [user@host ~]$ oc adm policy add-cluster-role-to-user cluster-admin username To remove a cluster role from a user, use the remove-cluster-role-from-user subcommand: [user@host ~]$ oc adm policy remove-cluster-role-from-user cluster-role username For example, to change a cluster administrator to a regular user, use the following command: [user@host ~]$ oc adm policy remove-cluster-role-from-user cluster-admin username Rules are defined by an action and a resource. For example, the create user rule is part of the cluster-admin role. You can use the oc adm policy who-can command to determine if a user can execute an action on a resource. For example: [user@host ~]$ oc adm policy who-can delete user ```

Default Roles

OpenShift ships with a set of default cluster roles that can be assigned locally or to the entire cluster. You can modify these roles for fine-grained access control to OpenShift resources, but additional steps are required that are outside the scope of this course.

Default roles | Description -- | -- admin | Users with this role can manage all project resources, including granting access to other users to access the project. basic-user | Users with this role have read access to the project. cluster-admin | Users with this role have superuser access to the cluster resources. These users can perform any action on the cluster, and have full control of all projects. cluster-status | Users with this role can get cluster status information. edit | Users with this role can create, change, and delete common application resources from the project, such as services and deployments. These users cannot act on management resources such as limit ranges and quotas, and cannot manage access permissions to the project. self-provisioner | Users with this role can create new projects. This is a cluster role, not a project role. view | Users with this role can view project resources, but cannot modify project resources.

[wangglbj]

The admin role gives a user access to project resources such as quotas and limit ranges, and also the ability to create new applications. The edit role gives a user sufficient access to act as a developer inside the project, but working under the constraints configured by a project administrator.

Project administrators can use the oc policy command to add and remove namespace roles. Add a specified role to a user with the add-role-to-user subcommand. For example: [user@host ~]$ oc policy add-role-to-user role-name username -n project

For example, to add the user dev to the role basic-user in the cpd-instance project: [user@host ~]$ oc policy add-role-to-user basic-user dev -n cpd-instance User Types

Interaction with OpenShift Container Platform is associated with a user. An OpenShift Container Platform user object represents a user who can be granted permissions in the system by adding roles to that user or to a user's group via rolebindings.

Regular users

Most interactive OpenShift Container Platform users are regular users, represented with the User object. This type of user represents a person that has been allowed access to the platform. Examples of regular users include user1 and user2.

System users

Many system users are created automatically when the infrastructure is defined, mainly for the purpose of enabling the infrastructure to securely interact with the API. System users include a cluster administrator (with access to everything), a per-node user, users for routers and registries, and various others. An anonymous system user is used by default for unauthenticated requests. Examples of system users include: system:admin, system:openshift-registry, and system:node:node1.example.com.

Service accounts

These are special system users associated with projects. Some service account users are created automatically when the project is first created. Project administrators can create more for the purpose of defining access to the contents of each project. Service accounts are often used to give extra privileges to pods or deployments. Service accounts are represented with the ServiceAccount object. Examples of service account users include system:serviceaccount:default:deployer and system:serviceaccount:foo:builder.

Every user must authenticate before they can access OpenShift Container Platform. API requests with no authentication or invalid authentication are authenticated as requests by the anonymous system user. After successful authentication, policy determines what the user is authorized to do.

[wangglbj]

References

For more information about Kubernetes namespaces refer to the Kubernetes Documentation

For more information about RBAC, refer to the Using RBAC to define and apply permissions chapter in the Red Hat OpenShift Container Platform 4.6 Authentication and authorization documentation at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html-single/authentication_and_authorization/index#using-rbac

For more information about groups, refer to the Understanding authentication chapter in the Red Hat OpenShift Container Platform 4.6 Authentication and authorization documentation at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html-single/authentication_and_authorization/index#understanding-authentication