Configure an Identity Provider in OpenShift

Container orchestration is a fundamental enabler of digital transformation initiatives in today’s world. Most of the applications in today’s world are running in containers in the form of microservices.

However, as monolithic applications transition to containerized services, it can be tedious to manage these applications with legacy infrastructure. Red Hat OpenShift Container Platform ( RHOCP ) helps developers and IT organizations to better manage application life cycles.

Red Hat OpenShift is based on the Kubernetes open-source project and extends the platform with features that bring a robust, flexible, and scalable container platform to customer data centers, enabling developers to run workloads in a high availability environment.

Red Hat OpenShift is a leading enterprise Kubernetes platform that enables a cloud-like experience everywhere it’s deployed. Whether it’s in the cloud, on-premise, or at the edge, Red Hat OpenShift gives you the ability to choose where you build, deploy, and run applications through a consistent experience. Red Hat OpenShift’s full-stack automated operations and self-service provisioning for developers let teams work together more efficiently to move ideas from development to production.

What is Red Hat OpenShift?

Red Hat OpenShift provides many services and features for the easy management of an application.

OpenShift Services and Features.

Now let us come to the topic of the Authentication of users in OpenShift. 🧑‍💻

When we set up the cluster for the first time using the installer program then a Kubeadmin user is automatically created by OpenShift to administer the OpenShift cluster.

Now as a good practice we need to delete the Kubeadmin user and create our own user with the cluster-admin power to administer the OpenShift cluster. For this purpose, we use an Identity Provider to create users who can access the cluster resources.

To control access to an OpenShift Container Platform cluster, a cluster administrator can configure user authentication and ensure only approved users can access the cluster.

Describing OpenShift Users and Groups 🧑‍💻

🔹User — In the OpenShift Container Platform architecture, users are entities that interact with the API server.

🔹Identity — The identity resource keeps a record of successful authentication attempts from a specific user and identity provider. Any data concerning the source of the authentication is stored on the identity. Only a single user resource is associated with an identity resource.

🔹Group — Groups represent a specific set of users. Users are assigned to one or multiple groups. Groups are leveraged when implementing authorization policies to assign permissions to multiple users at the same time. For example, if you want to allow 10 users access to certain resources of a project, then it is advantageous to grant access to the group of 10 users rather than granting access individually.

OpenShift Container Platform also provides system groups or virtual groups that are provisioned automatically by the cluster.

Now let us get on with the task of Configuring the Identity Provider of OpenShift for user authentication. 🧑‍💻

About identity providers in OpenShift Container Platform

By default, only the kubeadmin virtual user exists in your cluster. To create other users and to specify an identity provider, we must create a Custom Resource ( CR ) that describes that identity provider and add it to the cluster.

Let us first understand something about the identity provider configuration —

The OpenShift Container Platform master includes a built-in OAuth server. Developers and administrators of OpenShift obtain the OAuth access tokens to authenticate themselves to the API server.

As an administrator of the cluster, we can configure the OAuth to specify an identity Provider after we install the cluster. This is what we are trying to achieve here in this blog by creating the HTPasswd identity provider.

Configuring the HTPasswd Identity Provider —

The HTPasswd Identity Provider validates users against a secret that contains the credentials of the users. The credentials — username and password are generated with the htpasswd command from the Apache HTTP Server Project.

📌 Only a cluster administrator can change the data inside the HTPasswd secret. Regular users cannot change their own password.

Source: Google images.

To define an HTPasswd Identity Provider you must perform the following steps —

1. Create a file containing the credentials of the users using the htpasswd command.
2. Create a secret from the file created in the previous step.
3. Define the HTPasswd Identity Provider custom resource (CR).
4. Apply the custom resource to the default OAuth configuration.

Managing users with the HTPasswd Identity Provider —

Managing user credentials with the HTPasswd Identity Provider requires creating a temporary file, making changes to this file, and applying these changes to a secret.

📌 Step 1 — Creating the file containing user credentials.

To create the file using the htpasswd command we need to first install the package providing the command.

• On Red Hat Enterprise Linux, the htpasswd command comes from the httpd-tools package.

sudo yum install httpd-tools -y

Now, let’s add some user credentials in a file using the htpasswd command.

htpasswd -cBb  /path/to/file  <username>   <password>

The options used in the above command —

• " -c " — To create a new file for storing the user credentials. This option is used only when there is no pre-existing file for the user credentials.
• " -b " — To take the password for the user from the command line rather than prompting for it.
• " -B " — Force bcrypt encryption of the password. It’s very secure. Other types of encryption of the password are also available which can be used. By default MD5 encryption is used if no other options are mentioned.

Example usage —

Creating the user credentials.

❗For the remaining users also follow the same process, only removing "-c" option from next time as then it will overwrite the pre-existing file. ❗

If you want to delete the credentials of a user then use —

htpasswd  -D  /path/to/file  <username> 

Now it’s time to log in to our Red Hat OpenShift Cluster and configure our identity provider by performing the remaining steps. 🧑‍💻

oc login -u kubeadmin -p ${KUBEADMIN_PASSWORD}  <Cluster API URL>

📌 Step 2 — Creating the HTPasswd Secret.

To use the HTPasswd Identity Provider we have to create a secret that contains the user credentials from the flat file created in the previous step.

This is done so that OpenShift knows from where to validate the user credentials when one tries to authenticate themselves while logging into the OpenShift cluster.

• We need to create the secret in the openshift-config namespace as OpenShift reads all the internal configuration-related information from this namespace resources.

oc create secret generic  <secret name>  \
--from-file  htpasswd=/path/to/file  -n openshift-config

NOTE: The secret key containing the user's file for the " --from-file " option must be named htpasswd as shown in the above command.

Secret created for storing user credentials.

📌 Step 3 — Configuring the OAuth Custom Resource.

To use the HTPasswd Identity Provider, the OAuth custom resource must be edited and then replaced with the existing one.

Sample identity provider CR —

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

OAuth Custom Resource.

1 — The provider name is prefixed to provider user names to form the identity name.

2 — An existing secret in the openshift-config namespace containing the file having the user credentials generated using htpasswd.

The mappingMethod defines how identities are mapped to users when they log in. There are many possible values for this parameter — claim, lookup, generate, add.

Now we have to apply the custom resource YAML file to bring the changes into effect.

oc apply -f oauth.yaml

When we apply the custom resource, it will trigger new pods in the openshift-authentication namespace. The pods in this namespace will redeploy themselves to bring the new changes into effect. After the new pods are running, then we can log in with the new user credentials that we have updated using htpasswd.

The initial state of pods in the openshift-authentication namespace.

Now we are going to apply our custom resource ( CR ) file.

After applying the oauth.yaml file.

As we can see the pods in the openshift-authentication namespace that were present previously got terminated and new pods were deployed.

Now we can successfully log in with the new user in the OpenShift cluster.

Successful login of the new user.

After you have logged in, OpenShift will create the identity entry which we can check using the following commands —

$ oc get users
$ oc get identity

User and identity created after login.

For checking this you need to switch to the kubeadmin user or any user with cluster-admin power.

Updating users for an HTPasswd Identity Provider —

Now if you want to add or remove users from an existing HTPasswd Identity Provider, then you need to follow the following steps —

1. Extract the existing secret that has the user credentials.
2. Update that file with the new user details or delete the user credential that you want to remove.

Extracting Secret Data —

When adding or removing a user, the cluster administrator cannot assume the validity of a local htpasswd file. Moreover, the administrator may not be on a system that has the htpasswd file. So in the real-world scenario, the best practice is to extract the secret and update that.

oc extract secret/<secret name>  -n  openshift-config  \
  --to  /path/to/folder   --confirm

Here the --confirm option replaces the file in the location specified if it already exists there.

Extracting the secret data.

As we can see in the above image, the secret containing the user credentials is extracted and a file with the key name “htpasswd” is created in the mentioned location.

Now let’s add another user.

New user addition.

After the new user credentials have been generated, we need to update the secret.

Updating HTPasswd Secret —

oc set data secret/<secret name>  \
 --from-file  /path/to/file   -n openshift-config

Updating the secret.

After updating the secret, the OAuth operator redeploys the pods in the openshift-authentication namespace. Monitor the redeployment of the pods using -

oc get pods -n openshift-authentication -w

New pods are being redeployed.

This way you can add multiple users.

Deleting Users and Identities —

When we need to delete a user, it is not sufficient to delete the user from the identity provider. The user and the identity resources must also be deleted otherwise it might lead to a conflict later on.

• We must remove the credentials from the htpasswd secret, remove it from the htpasswd file and then update the secret.

Extracting the secret, deleting the user credentials from the file, and then updating the secret — all the required commands and procedure have been provided previously in the blog.

After this, we need to delete the user and the identity resource.

Incorrect login attempt.

This type of error message you will get when you update the secret by removing the user credentials.

But the user and the identity resource of the user still exist.

User and identity of deleted user.

Remove the user and the identity with the following commands —

oc delete user  <username>
oc delete identity  <identity name>

Deleting the user and the identity resource.

As you can see the user and the identity resource of the user are also removed now.

Managing users using the HTPasswd identity provider might suffice for a proof-of-concept, environment with a small set of users. However, most production environments require a more powerful identity provider that integrates with the organization’s identity management system.

So, with that, we come to an end to this article. 💖

Hope you got a simple understanding of how to configure an identity provider in Red Hat OpenShift Container Platform.

I would definitely like to hear your reviews and feedback which will help me in improving my content in future technical blogs. 🗃️🙏

You can check my LinkedIn profile and connect with me and also follow me on medium.

Rahul Sil - ARTH Learner - ARTH - The School of Technologies | LinkedIn

That’s all for now. Thank You !! 😊✌