Multitenancy and role-based access control in Red Hat OpenShift
Isolate your workloads with role binding
Multitenancy is an architecture in which a single instance of a software application serves multiple customers (tenants), where each tenant’s data is logically separated from the other tenants. Role-based access control (RBAC) is a method of restricting access based on the roles of the users in the cluster, where users have the rights to access the resources they need. In RBAC, role bindings define which users are entitled to view and manage authorized resources, and they grant the permissions defined in a role to a user or a group. While a role binding grants permissions at a project scope, cluster role binding grants permissions at a cluster level.
This tutorial shows how you can achieve multitenancy by using Red Hat OpenShift Container Platform RBAC and role binding. It walks you through creating a project in OpenShift, adding users to the cluster, and then using role bindings to limit the users to specific projects (namespaces) to ensure that their workloads are isolated from other users. Their resources and views are separated from other users on the same OpenShift cluster using the same set of shared hardware resources. You also learn how to impersonate a user, which administrators can use to troubleshoot a user’s issues on the cluster. In this tutorial, we use impersonation to show you the cluster view of a user.
For this tutorial, you need:
- A Red Hat OpenShift 4.3 cluster or above on IBM Cloud
- IBM Cloud Shell
It will take you around 30 minutes to complete this tutorial.
- Log in and create projects
- Create users
- Create role bindings
- Impersonate user and deploy application
- Create and deploy the pod
- Switch to another user
Log in and create projects
We create users and projects with the IBM Cloud Shell because you cannot create local users from the web console.
Log in to the Red Hat OpenShift for IBM Cloud web console for your cluster. Click your username in the header and then click Copy Login Command. Click Display Token and copy the
oc logincommand and paste it in your terminal.
Create two projects, one for each user in our example, by copying the following commands in your terminal:
oc create namespace my-first-project
You see a message that
my-first-projecthas been created.
oc create namespace my-second-project
You see a message that
my-second-projecthas been created.
Copy and paste the following commands on the command line to create two users:
oc create user first-user --full-name="first user"
You see a message that
first-userhas been created.
oc create user second-user --full-name="second user"
You see a message that
second-userhas been created.
As Administrator, you can see all the users, projects, and pods associated with the cluster.
In the web console, click User Management > Users to see the new users listed.
Click Home > Projects to view all the projects in the cluster.
Click Workloads > Pods to view all pods (make sure that you click Project > all projects to list all of the projects).
Version 4.3 of the OpenShift web console UI added the ability to spoof other users and groups. Let’s impersonate one of the users to see what that user has access to at this point.
Click User Management > Users and then click the vertical ellipsis button for first-user. Click Impersonate User first-user.
If you click Home > Projects, you can see that
first-user can’t view any projects/pods or create any new projects/pods. That’s because
first-user doesn’t have a role binding yet, which means
first-user does not have any privileges and/or permissions to create, view, or manage projects and pods.
Click Stop Impersonation in the Impersonating User header to stop impersonating
first-user and switch back to Administrator.
Create role bindings
In this step, you create role bindings to give users access to their respective projects. You can easily create role bindings through the web console.
- Click User Management > Role Bindings.
- Click Create Binding.
On the Create Role Binding page, fill out the form as follows and click Create:
- Binding Type: Namespace Role Binding (RoleBinding)
- Name: first-user-rb
- Namespace: my-first-project
- Role Name: cluster-admin
- Subject: User
- Subject Name: first-user
Click User Management > Users and click first-user. Click the Role Bindings tab, and you can see that the role
cluster-adminhas been successfully associated with
first-user-rbrole binding for the namespace
Impersonate user and deploy application
In this step, you impersonate
first-user like you did previously, but this time,
first-user has admin permissions to
my-first-project, which means
first-user can do everything an admin can do on that namespace.
Click User Management > Users and then click first-user. Click Actions > Impersonate Users first-user.
Notice that now
first-usercan view the
my-first-projectnamespace. It is the only project this user can view because
first-userwas limited to the
Click Workloads > Pods to see that
first-userhas access to the pods as well (and can create pods), but no pods have been created yet.
Create and deploy the pod
In this step, you create a pod as
first-user in the
- Switch to the Developer Perspective on the web console.
Click Topology, and then click Container Image.
On the Deploy Image page, enter
ibmcom/guestbook:v1in the Image name from external registry field. (You should see a Validated messsage. Keep the default settings and click Create.
Once you create the pod, you are redirected to the Topology view, which shows the pod. The light blue circle around the pod turns dark blue once it successfully builds. As
first-user, you can successfully deploy a containerized application (guestbook:v1) in the project
my-first-project and can view the pods and deployment resources associated with the application.
You can access the deployed application by clicking on the small square on the top corner of the pod, which opens Guestbook-v1 in a new window.
In the web console, switch back to the Administrator perspective. Notice that the new pod has been added to the list of pods for the project
Switch to another user
Now, let’s stop the impersonation for
first-user, and switch to
second-user to verify if
second-user can see the pods
- Click Stop Impersonation in the Impersonating User header to stop impersonating
first-userand switch back to Administrator.
- Click User Management > Users and then click the vertical ellipsis button for second-user. Click Impersonate Users second-user.
second-user cannot see the project
second-user is not authorized.
Thanks to role bindings in OpenShift, we have isolated the workloads across users on the cluster and achieved multitenancy. As a real-world use case, a managed service provider could use this feature to provide logical isolation to its customers while using the same OpenShift Container Platform cluster and the same set of shared hardware resources.