Introduction

One feature that Openshift provides on top of Kubernetes is the ability to configure a series of Identity Providers for authentication against the API. For that, Openshift master includes a built-in OAuth server that can be configured right after the cluster installation.

That being said, after providing an article about Openshift Project Templates, this article continues the series of articles related to Openshift Administration topics, presenting a how-to configure an HTPasswd identity provider for configuring local users and granting them the ability to log in to your Openshift cluster.

The Use Case

Our use case is pretty simple: as Openshift administrators, we are handed over a new cluster containing only the kubeadmin user configured, and our tasks are:

1. configure the following four local users into our system: sayajin_admin, giga_dev, spider_dev, and awesome_tester.
2. The user sayajin_admin should be a cluster-admin.
3. Only the newly created admin user should be able to create projects
4. for security measures, our task is to remove the ability from the kubeadmin user from logging into the system.

Generating an HTPasswd file

Before even touching our Openshift cluster, the first step is to generate a credentials flat file that will host the list of users that will login into our cluster.

For that, we will make use of the htpasswd utility available on RedHat Enterprise Linux systems via the httpd-tools package. If the binary is not available on your host you can install it with the following command:

$ yum install httpd-tools -y

Once installed, the following four commands will create the htpasswd flat file with the desired four users:

$ htpasswd -B -b -c /tmp/htpasswd sayajin_admin ${password}
$ htpasswd -B -b /tmp/htpasswd giga_dev ${password}
$ htpasswd -B -b /tmp/htpasswd spider_dev ${password}
$ htpasswd -B -b /tmp/htpasswd awesome_tester ${password}

Note that the first command contains the parameter -c that instructs the tool to create the file as it does not originally exist. The successive commands will append to the existing command thus the parameter is removed.
The parameter -b states it should take the password from the command line rather than a password prompt, and any password you desire via the substitution can replace the password parameter.
Last, the -B command instructs the password to be stored in the flat file with the bcrypt encryption, which is considered safe encryption.

Once run, we can inspect our file which should present entries for our four users:

$ cat /tmp/htpasswd
sayajin_admin:$2y$05$w.aqkirhNN36fX64jrwQg.qEoZH1Mivkf2yxTAveOl4LgqjKBMjxG
giga_dev:$2y$05$w.Y.ISdftvbMUNLQXvdUtu8kyYvICbGh8zZ/J23/bOC56kVBoKw9C
spider_dev:$2y$05$LTLP34dVUqj9WBNr6cKcdOcETTsfjlSkNYBGqtq081Zj3ZP77nXSW
awesome_tester:$2y$05$aWiKhT.ZEvtT5h0WpUcbS.Y2tQlMILudd7ueyxOnY8BOm3CmdQRge

Configuring the HTPasswd provider

The first step to configure our htpasswd provider is to store our flat file in a secret so it can be consumed by the OAuth server. We can achieve this with the following command:

$ oc create secret generic htpasswd --from-file=/tmp/htpasswd -n openshift-config

The point of interest on this secret is that we must create it in the namespace openshift-config, as this is the namespace in which the OAuth configuration inspects the identity provider configuration.

Once created, we can configure the OAuth custom resource:

$ oc edit oauth cluster

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

The specification of the OAuth custom resource is pretty simple: we show we are configuring an HTPasswd via the type property while directing the htpasswd.fileData.name entry to the secret htpasswd previously created.

Once edited, we can inspect the pods on the namespace openshift-authentication that should restart sequentially. Once restarted, we should be able to login with any of the configured htpasswd users.

$ oc get pod -n openshift-authentication
NAME                              READY   STATUS                  RESTARTS   AGE
oauth-openshift-7cbfdcf57-9nkqd   0/1     Terminating             0          5d5h
oauth-openshift-7cbfdcf57-htgbc   1/1     Running                 0          5d5h
oauth-openshift-7cbfdcf57-znzpv   1/1     Running                 0          5d5h
oauth-openshift-7cbfdcf57-4nddw   0/1     ContainerCreating       0          2s

Granting and Restricting User Permissions

For the second requirement, we are asked to grant our user sayajin_admin cluster administration rights, a requirement achieved with the following command:

$ oc adm policy add-cluster-role-to-user cluster-admin sayajin_admin

The third requirement is to allow only cluster administration users to create projects. By default, any user that is part of the group system:authenticated:oauth can create projects, so currently, all users from the HTPasswd provider have such rights, and must remediate this.

The self-provisioner is the ClusterRole resource that allows users to create projects and we can confirm that users from the mentioned group have this role by inspecting the following self-provisioners clusterrolebinding:

$ oc describe clusterrolebinding self-provisioners
Name:         self-provisioners
Labels:       
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  self-provisioner
Subjects:
  Kind   Name                        Namespace
  ----   ----                        ---------
  Group  system:authenticated:oauth

We can remove this permission with the following command:

$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

Once executed, attempting to describe again the self-provisioners clusterrolebinding will throw a not found error as the clusterrolebinding will be removed automatically once we revoke the self-provisioner permission with the previous command.

Now only our administrator user sayajin_admin will create projects (other than the kubeadmin user, which we will address shortly). If you attempt to create a new project with the spider_dev user as an example, you will observe the following error:

$ oc new-project apollo
Error from server (Forbidden): You may not request a new project via this API

Removing the kubeadmin access

For security reasons and as a good practice, once we have configured a new cluster administrator user, we are asked to remove the default kubeadmin user from the system. We can simply achieve this with the following command:

oc delete secrets kubeadmin -n kube-system

IMPORTANT: It is imperative that before deleting the kubeadmin user, you configure a new cluster administrator user. Failing to do so will cause you to no longer be able to log in with any administrative user blocking you from performing any meaningful action in the cluster.

Conclusion

This post covered the basics of the Openshift Identity Providers configuration, and a simple HTPasswd identity provider was configured to enable local users stored as a secret within the Openshift cluster to log in. As previously mentioned, other than a flat htpasswd file, Openshift supports a series of other providers and you can find more information about their similar but different configurations on the Openshift official documentation.

Identity Providers configuration is also a must-know topic if you are looking to get certified via the Red Hat Certified Specialist In OpenShift Administration (RHCSOA), so I highly recommended you have a go at configuring a custom identity provider for your environment as a way of acquiring the required experience for the exam.

Stay tuned for more Kubernetes and Openshift content and until next time!