Openshift - Set Up htpasswd as the Identity Provider and Add Users and Permissions

There are several reasons why default permissions should be changed or assigned in the OpenShiftenvironment. In OpenShift, there are 7 default roles that you can bind to groups or users, cluster-wide or locally.

• These 7 roles are:

1. Admin
2. Basic-user
3. Cluster-admin
4. Cluster-status
5. Edit
6. Self-provisioner
7. View

• Below are some questions the users might have:

1. How can we add/create read-only users?
2. How to create a cluster admin user than the default admin user?
3. How to add a super-user that can perform any action in any project?
4. How to add the user who has full control of the quota and every action on every resource in the project and nothing outside of that project?

This article explains how to create a single user and multiple users in one go. It then explains how to assign specific roles and permissions to each user.

1] For testing purposes, we have used the below list of users to Create htpasswd file with users and their passwords.

• swapnil
• abc
• xyz
• admin
• cnp

To add the single user with its password you can use the below command (Here I use user: CNP password: CNP)

edb@localhost ~ % htpasswd -c -B -b users.htpasswd cnp cnp
Adding password for user cnp

edb@localhost ~ % cat users.htpasswd
cnp:$2y$05$6KPN/3/uuQrCMe6yUPYV2OVUB6yWkfcfXNpLbU4lprnLRWXJ2P36m

To add Multiple users with passwords you can use the below command (Here I user Password: CNP for users: swapnil, abc, xyz, admin, cnp )

edb@localhost ~ % for users in swapnil abc xyz admin cnp;
for> do htpasswd -B -b users.htpasswd $users cnp;
for> done
Adding password for user swapnil
Adding password for user abc
Adding password for user xyz
Adding password for user admin
Adding password for user cnp
edb@localhost ~ % 

2] Create HTPasswd Secret from file.

List all secrets from your namespace

edb@localhost ~ % oc get secret -n openshift-config   
NAME                   TYPE                 DATA  AGE
builder-dockercfg-gdlx2          kubernetes.io/dockercfg        1   44d
builder-token-5p94p            kubernetes.io/service-account-token  4   44d
default-dockercfg-ptgzw          kubernetes.io/dockercfg        1   44d
default-token-pvhk9            kubernetes.io/service-account-token  4   44d
deployer-dockercfg-jd2r9         kubernetes.io/dockercfg        1   44d
deployer-token-q8m67           kubernetes.io/service-account-token  4   44d
etcd-client                kubernetes.io/tls           2   44d
etcd-metric-client            kubernetes.io/tls           2   44d
etcd-metric-signer            kubernetes.io/tls           2   44d
etcd-signer                kubernetes.io/tls           2   44d
htpass-secret               Opaque                1   43d
initial-service-account-private-key    Opaque                1   44d
login-template              Opaque                1   43d
pull-secret                kubernetes.io/dockerconfigjson    1   44d
webhook-authentication-integrated-oauth  Opaque                1   44d

3] Delete the htpass-secret file:

edb@localhost ~ % oc delete secret htpass-secret -n openshift-config
secret "htpass-secret" deleted

4] Create the generic htpass-secret file:

edb@localhost ~ % oc create secret generic htpass-secret --from-file=htpasswd=users.htpasswd -n openshift-config
secret/htpass-secret created

5] Download the HTPasswd Custom Resource (using the link provided HERE).

edb@localhost ~ % wget https://raw.githubusercontent.com/linuxacademy/content-openshift-2020/master/htpasswd_cr.yaml

6] Add the name of your HTPasswd Secret to the file.

edb@localhost ~ % vim htpasswd_cr.yaml

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
 name: cluster
spec:
 identityProviders:
 - name: users.htpasswd
  mappingMethod: claim
  type: HTPasswd
  htpasswd:
   fileData:
    name: htpass-secret

7] Apply your custom resource to your cluster htpasswd_cr.yaml:

edb@localhost ~ % oc apply -f htpasswd_cr.yaml
oauth.config.openshift.io/cluster configured

8] Test your users by login to openshift

edb@localhost ~ % oc login -u admin
Authentication required for https://api.crc.testing:6443 (openshift)
Username: admin
Password: 
Login successful.

You don't have any projects. You can try to create a new project, by running

  oc new-project <projectname>

edb@localhost ~ % oc whoami 
admin

edb@localhost ~ % oc login -u cnp
Authentication required for https://api.crc.testing:6443 (openshift)
Username: cnp
Password: 
Login successful.

You don't have any projects. You can try to create a new project, by running

  oc new-project <projectname>

edb@localhost ~ % oc whoami 
cnp

1. Admin role: This role has the rights to view any resource in the project and modify any resource in the project except for quota, which means, they can do everything but set quotas for specific applications or set resource limits.

2. Basic-user role: They can get basic information about projects and users.

3. Cluster admin role: This one works in 2 different ways. First off, if you assign a user cluster-admin without specifying a project, it's basically a super-user that can perform any action in any project. Now, if you bind it to a specific project, the user has full control of quota and every action on every resource in the project and nothing outside of that project.

4. Cluster-status role: which can get basic cluster status information.

5. Edit role: This role will allow users to modify most objects in a project, but does not have the power to view or modify roles or bindings.

6. Self-provisioner role: which can create their own projects. So this is good, especially in a dev environment to allow developers the ability to provision their own project, to deploy their application in.

7. View role: The view role can't make any modifications, but can see most objects in a project. It also cannot view or modify roles and bindings. This is a good role to set for users on like a production-level environment where you don't want them to make changes, but you want them to be able to view what's going on within their project.

• To assign the specific permissions I have created a project called demoproject.

edb@localhost ~ % oc new-project demoproject
Now using project "demoproject" on server "https://api.crc.testing:6443".

You can add applications to this project with the 'new-app' command. For example, try:

oc new-app rails-postgresql-example

To build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:

kubectl create deployment hello-node --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 -- /agnhost serve-hostname

1. Give cnp admin permissions to the demoproject project.

edb@localhost ~ % oc adm policy add-role-to-user admin cnp -n demoproject
clusterrole.rbac.authorization.k8s.io/admin added: "cnp"
edb@localhost ~ % 

2. Give swapnil and abc edit permissions to the demoproject project.

edb@localhost ~ % oc adm policy add-role-to-user edit swapnil -n demoproject
clusterrole.rbac.authorization.k8s.io/edit added: "swapnil"

edb@localhost ~ % oc adm policy add-role-to-user edit abc -n demoproject
clusterrole.rbac.authorization.k8s.io/edit added: "abc"

3. Give xyz basic user permissions to the demoproject project.

edb@localhost ~ % oc adm policy add-role-to-user basic-user xyz -n demoproject
clusterrole.rbac.authorization.k8s.io/basic-user added: "xyz"
edb@localhost ~ % 

4. Give admin cluster-admin permissions.

edb@localhost ~ % oc adm policy add-cluster-role-to-user cluster-admin admin         
clusterrole.rbac.authorization.k8s.io/cluster-admin added: "admin"
edb@localhost ~ %

5. Try to remove the kubeadmin user from the cluster after assigning admin permissions to user admin

edb@localhost ~ % oc login -u admin
Logged into "https://api.crc.testing:6443" as "admin" using existing credentials.

You have access to 69 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "demoproject".

edb@localhost ~ % oc delete secrets kubeadmin -n kube-system