Grant Users Access to Project/Namespace in OpenShift

Projects in OpenShift are the unit of isolation and collaboration. For developers to deploy applications they need to be members of a project. Within a project, members may have different roles – admin, edit, view, e.t.c. As a project administrator you can add users to the cluster and assign them particular permissions. Below are the pre-defined roles in OpenShift.

• edit: A user that can modify most objects in a project, but does not have the power to view or modify roles or bindings.
• admin: An admin user have rights to view any resource in the project and modify any resource in the project except for quota.
• cluster-admin: A super-user that can perform any action in any project. When bound to a user with a local binding, they have full control over quota and every action on every resource in the project.
• basic-user: A user that can get basic information about projects and users.
• cluster-status: A user that can get basic cluster status information.
• self-provisioner: A user that can create their own projects.
• view: A user who cannot make any modifications, but can see most objects in a project. They cannot view or modify roles or bindings.

In this short guide we will create a test project, users and give them access to the project created. One of the users will have a view only access to the cluster and one user should be able to edit all resources in the namespace/project.

Create a Project on OpenShift

Create a project on OpenShift. This can be done on CLI or from the web console.

$ oc new-project test
Now using project "test" on server "https://api.devocp.example.com:6443".

You can then list all available projects to confirm the one we just created is available.

$ oc get projects

Grant User Access to OpenShift Project

You should have users already given access to the OpenShift cluster before you can grant them permissions to access a Project. There are multiple providers that can be used to authenticate users in OpenShift. We recently created an article on using HTPasswd to manage OpenShift cluster users.

Manage OpenShift / OKD Users with HTPasswd Identity Provider

You can get a list of users who have already logged in to the cluster with oc get users command:

$ oc get users
JKMUTAI     17a06002-b543-4fa9-bfa8-92e510646d0a   Josphat Mutai                HTPasswd: Q049Sm9zcGhhdCBNdXRhaSxPVT1TYWZhcmljb20gRGVwYXJ0bWVudHMsREM9c2FmYXJpY29tLERDPW5ldA

Grant a user access to the project with rolebinding. The syntax to use is:

$ oc adm policy add-role-to-user   -n 

To assign JKMUTAI user edit role in the test project I’ll run the following commands.

$ oc adm policy add-role-to-user edit JKMUTAI -n test
clusterrole.rbac.authorization.k8s.io/edit added: "JKMUTAI"

For Cluster role use the command:

$ oc adm policy add-cluster-role-to-user edit JKMUTAI -n test

To remove role from the user, use:

$ oc adm policy remove-role-from-user   -n 
$ oc adm policy remove-cluster-role-from-user   -n 

If you want to get a list of users who have access to the project run the following command:

$ oc get rolebindings -n 
$ oc get rolebindings  -n 

Sample output:

You can login from from the CLI or Console and confirm you can switch to the project for applications deployment.

$ oc login

Switch to the project with the command:

$ oc project test
Already on project "test" on server "https://api.example.com:6443".

Deploy test application.

oc apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: command-demo
  labels:
    purpose: demonstrate-command
spec:
  containers:
  - name: command-demo-container
    image: debian
    command: ["printenv"]
    args: ["HOSTNAME", "KUBERNETES_PORT"]
  restartPolicy: OnFailure
EOF

Confirm the container is running:

$ oc get pods

Screenshot:

More on OpenShift:

Configure Chrony NTP Service on OpenShift 4.x / OKD 4.x

How To Allow Insecure Registries in OpenShift / OKD 4.x Cluster

How To Check Pod / Container Metrics on OpenShift & Kubernetes