Posted: August 4, 2022 | %t min read | by Robert Kimani

In cloud computing, role-based access control (RBAC) connects a user to a specific role, where a role is a collection of permissions applied to either a project or to an entire cluster. To work with RBAC, you must recognize that different types of users exist, and each can be used with these roles.

Verbs such as get, list, watch, delete, deletecollection, create, update, and patch are used to manage permissions. They're crucial parameters when defining roles, which are API resources that provide access to OpenShift resources.

OpenShift, Red Hat's enterprise-ready Kubernetes container platform, includes several cluster roles by default. In most cases, the default roles are all you need when setting up user permissions. However, understanding users and roles is an important part of managing a cluster with OpenShift.

User types

A user is granted access to cluster resources using role bindings and is created as a specific user type. For example, there are regular users, system users, and service accounts.

• The regular user role defines an object granted access to a cluster platform.
• The system user role is automatically created when infrastructure is defined to allow system components access to a specific resource.

Examples of system users include:

• The system:admin account provides full admin access.
• The system:openshift-registry account offers registry access.
• The system:node:server1.example.com account gives node access.
• An anonymous user account is for unauthenticated requests.

• The service account role is a special system account (often generated automatically at project initialization) that provides extra privileges to pods or deployments.

[ Get this complimentary eBook from Red Hat: Managing your Kubernetes clusters for dummies. ]

Examples of service accounts and their functions include:

• The system:serviceaccount:default:deployer service accounts are used to create deployments.
• The system:serviceaccount:foo:builder service accounts are used to create configurations in Source-to-image (S2I).

Default roles

In most cases, OpenShift's default roles are sufficient for setting up permissions for users. They can be applied locally or to the entire cluster.

• Image

  

  Download now

  The view role allows users to view but not modify any project resources.

• The edit role permits modifying and creating common application resources but gives no access to permissions, limit ranges, or quotas that also correspond to the typical developer user.
• The self-provisioner role allows users to create new projects (all users have self-provisioner by default).
• The basic-user role provides read access to projects.
• The cluster-admin role allows users to perform any action in the cluster.
• The cluster-status role permits users to request status information.
• The admin role gives full control and permissions to project resources.

Sometimes, you need more granularity when granting permissions. You can achieve this by creating either a local role or a cluster role to provide access to project-based resources.

Create a custom local role

To create a custom local role, use the oc create command with the following syntax:

$ oc create role NAME --verb=VERB --resource=RESOURCE -n PROJECT

[ Learn some quick tips for using OpenShift's oc client. ]

The verb you use depends on the resource you're managing. For example, if you look at a pod as a resource, then valid verbs are get, create, or delete. If you want to grant a user permission to view pods within an OpenShift project called demo1, for example, type the following:

$ oc create role podview --verb=get --resource=pod -n demo1
role.rbac.authorization.k8s.io/podview created

Manage custom local role RBAC with oc adm policy

Cluster administrators use the oc adm policy command to manage cluster and namespace roles.

A role binding is essential because it connects your local custom roles and cluster roles to a user or group. Without a role binding, local roles and cluster roles are useless.

Add and bind the local custom role to a user in a specific namespace, and provide the role name and user name:

$ oc adm policy add-role-to-user podview johndoe --role-namespace=demo1 -n demo1
role.rbac.authorization.k8s.io/podview added: "johndoe"

Create a custom cluster role

Cluster roles can provide default permissions to any project. For example, you might create a cluster role to allow users to only view pods.

[ Get the Kubernetes glossary cheat sheet. ]

Creating a cluster role is similar to creating a custom local role. Use oc create clusterrole, along with a name for the role you're creating, a verb, and a resource to create a cluster role. Here is an example:

$ oc create cluster role podviewonly  --verb=get  --resource=pod
clusterrole.rbac.authorization.k8s.io/podviewonly created

Manage custom cluster role RBAC with oc adm policy

If you apply your new cluster role to a specific user, then that user can see pod information throughout the cluster. For this to be fully effective, you must add and bind this local custom cluster role to a user:

$ oc adm policy add-cluster-role-to-user podviewonly janedoe
clusterrole.rbac.authorization.k8s.io/podviewonly added: "janedoe"

Verify local role binding

To see which local roles are assigned to a specific project (in this case, demo1) with a non-cluster scope, use oc describe rolebinding.rbac:

$ oc describe rolebinding.rbac -n demo1 | grep podview -A 10
Name:         podview
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  podview
Subjects:
  Kind  Name     Namespace
  ----  ----     ---------
  User  johndoe  
Name:         system:deployers
Labels:       <none>
Annotations:  openshift.io/description:
                Allows deploymentconfigs in this namespace to rollout pods in this namespace.  It is auto-managed by a controller; remove subjects to disa...

Verify cluster role binding

For an overview of users, groups, and roles, use oc describe clusterrolebindings.rbac. This command checks the custom cluster local role binding to the podviewonly cluster role assigned to the user janedoe:

$  oc describe clusterrolebindings.rbac podviewonly

Name:         podviewonly
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  podviewonly
Subjects:
  Kind  Name     Namespace
  ----  ----     ---------
  User  janedoe 

[ Learn how to manage your Linux environment for success. ]

Learn RBAC

The oc adm policy command provides an overview of all security credentials with specific permissions to perform an action. The oc adm policy who-can command is very useful to view who has access to perform an action within a project. Here are two different ways of using this command:

$ oc adm policy who-can <verb> <resource>

$ oc adm policy who-can get pod
$ oc adm policy who-can delete user

Wrap up

This article introduces the basics of local roles and cluster roles for RBAC permissions. There's much more to learn, but the above information provides a head start. Explore OpenShift and its documentation to learn more.