How To Implement RBAC in OpenShift ?
Role Based Access Control (RBAC)
Role-based access control (RBAC) is a technique for managing access of resources in system. In 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 level of responsibility of the user: cluster role and local role.
RBAC Objects
There are 3 major objects in RBAC
- Rule: Allowed actions for objects or groups of objects
- Role: Sets of rules called as role. Users and groups can be associated with multiple roles.
- Binding: Assignment of users or groups to a role.
RBAC Scope
OpenShift defines two groups of roles (cluster roles and local roles) and bindings depending on the scope and responsibility of users.
- Cluster Role: Users or groups with this role level can manage the OpenShift cluster, they have the full control of cluster.
- Local Role: Users or groups with this role level can only manage elements at a project level, their scope is within the project.
Cluster role bindings take precedence over local role bindings.
Default Roles
OpenShift also provides a set of default cluster roles that can be assigned locally or to the entire cluster. We can modify these roles according to the requirements to access control the OpenShift resources.
- admin: Users with this role can manage all project resources, including granting access to other users to the project. a user with admin role can access to project resources such as quotas and limit ranges, and also the ability to create new applications.
- basic-user: Users with this role have read only 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, delete, and change common application resources from the project, such as services and deployment configurations. These users cannot act on management resources such as quotas and limit ranges, and cannot manage access permissions to the project. The edit role gives a user sufficient access to act as a developer inside the project, but working under the restraints configured by a project administrator.
- self-provisoner: This is a cluster role, not a project role. Users with this role can create new projects.
- view: Users with this role can view project resources, but cannot modify project resources.
To add a specific role to a user, we can use add-role-to-user command.
[user1@onionlinux ~]$ oc adm policy add-role-to-user role-name username -n project
For example, to add the user developer to the role basic-user in the nodejs project:
[user1@onionlinux ~]$ oc adm policy add-role-to-user basic-user developer -n nodejs
Managing RBAC using CLI
To add a cluster role to a user, use the add-cluster-role-to-user subcommand:
[user1@onionlinux ~]$ oc adm policy add-cluster-role-to-user cluster-role username
example, to change a regular user to a cluster administrator, use the following command:
[user1@onionlinux ~]$ 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:
[user1@onionlinux ~]$ oc adm policy remove-cluster-role-from-user cluster-role username
example, to change a cluster administrator to a regular user, use the following command:
[user1@onionlinux ~]$ oc adm policy remove-cluster-role-from-user cluster-admin username
Rules are defined by an action and a resource. i.e, the create user rule is part of the cluster-admin role.
We can use the oc adm policy who-can command to determine if a user can execute an action on a resource. For example:
[user1@onionlinux ~]$ oc adm policy who-can delete user
User Type
An OpenShift Container Platform user object represents a user who may be granted permissions in the system by adding roles to that user or to a user’s group via rolebindings. Interaction with OpenShift Container Platform is associated with a user.
There are mainly 3 types of users.
Regular User
This type of user represents a user that has been allowed access to the platform. Regular users are represented with user object. This is the most interactive way to access OpenShift Container Platofrm.
System User
System users include a cluster administrator (with access to everything), a per-node user, users for use by routers and registries, and various others. Many system users are created automatically when infrastructure is defined, mainly for the purpose of enabling the infrastructure to securely interact with the API. An anonymous system user also exists that is used by default for unauthenticated requests.
Service Accounts
Service accounts are generally used to give extra privileges to pods or deployment configurations. Service accounts are represented with the ServiceAccount object. These are special system users associated with projects; some are created automatically when the project is created, and project administrators can also create more for the purpose of defining access to the contents of each project.
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.
For more information about RBAC you can go here , and to get more about details about groups you can go here
You can read about OpenShift Container Platform Architecture in my another post Architecture of Kubernates & OpenShift.
I hope you like this post, if you have any questions? please leave comment below!
Thanks for reading. If you like this post probably you might like my next ones, so please support me by subscribing my blog.
You may also like : How To Read Electrical Schematics
