This blog will cover the “Manage users and policies” objective of the EX280 exam from RedHat. In this post we will:
- Configure the HTPasswd identity provider for authentication
- Create and delete users
- Modify user passwords
- Modify user and group permissions
- Create and manage groups
Will also sprinkle in a little bit from “Manage users and policies” with:
- Define role-based access controls
- Apply permissions to users
The most easy way to try OpenShift is by using CRC. In this case this gives as an advantage because HTPasswd is already set up. We will however be configuring it from the ground up using the example provided by the OpenShift documentation 1.
Setting up HTPasswd Authentication
One of the simplest way to authenticate users to a cluster is by using the HTPasswd provider. This is based on a text based secret containing a
username:password key-pair. It’s easy to set up and understand.
Creating the HTPasswd file
Creating a new HTPasswd file can be done in a single command from the command-line:
$ htpasswd -c -B -b FILENAME USERNAME PASSWORD
Let create our first user with username admin and password … dunder:
$ htpasswd -c -B -b htpasswd-file Michael dunder Adding password for user Michael
After creating the
htpasswd file we can drop the
-c (create) flag and add some more users:
$ htpasswd -B -b htpasswd-file Pam secret01 Adding password for user Pam $ htpasswd -B -b htpasswd-file Dwight secret02 $ htpasswd -B -b htpasswd-file Jim secret03
Warning: Usernames and passwords are case sensitive
And let’s have a look at our file:
$ cat htpasswd-file Michael:$2y$05$f2SD9CoUnLzqkA.AgTVToOb6fSKhmN.5xwHqq/Cz/zUZ4ZSXqsyze Pam:$2y$05$fRR.5EmSaDGd1rMtAygWxexpuiMGnZJOgk0Oo.kuocyKtKoin5Z0e Dwight:$2y$05$EKp1MLW/anaJ1R2wKpAkju6oPZvxV47tTtTq8KKp7x.cjFeOTke5u Jim:$2y$05$k1Nlh3ZhqY8E6wK.v1exfOuieLkmZT2MRwFFxVuYZ8KQZ3xcLHWg.
Applying secret to the cluster
In order to use our
htpasswd file we need to make it available in the cluster as a secret. I wrote about creating secrets before here.
We will create a secret called
htpasswd-source in the cluster with the content of our
htpasswd file. This has to be done in the project
$ oc create secret generic htpasswd-source \ --from-file htpasswd=htpasswd-file \ --namespace openshift-config secret/htpasswd-source created
Setting up the identity provider
Now that we have the secret in place we can create our identity provider. We will do this with the template thats available from the OpenShift Documentation 1 :
apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: custom_htpasswd_provider mappingMethod: claim type: HTPasswd htpasswd: fileData: name: htpasswd-source
By applying this
yaml to the cluster we will:
- Create a OAuth Identity provider called
- With the source secret
$ oc apply -f custom_htpasswd_provider.yaml \ --namespace openshift-config oauth.config.openshift.io/cluster configured
It might take a while but after some syncing in you cluster your new auth provider should be online. You can check this with
oc get oauth:
$ oc get oauth -o yaml apiVersion: v1 items: - apiVersion: config.openshift.io/v1 .... spec: identityProviders: - htpasswd: fileData: name: htpasswd-source mappingMethod: claim name: custom_htpasswd_provider type: HTPasswd ....
Viewing users and logging in
After getting our new authentication provider up and running we can test it by logging in with one of our new users. But first, lets take a look at the users we have:
$ oc get users NAME UID FULL NAME IDENTITIES developer 623cd251-b25b-44b5-a00e-67f311029588 developer:developer kubeadmin 06238f0b-4f58-45f2-9b61-94b482bb4b74 developer:kubeadmin
As you can see our new users are not yet listed. This is because they will be created after they log in. For example:
$ oc login -u Pam https://api.crc.testing:6443 Authentication required for https://api.crc.testing:6443 (openshift) Username: Pam Password: Login successful.
Switch back to a user with admin rights and check te users again:
$ oc login -u kubeadmin Logged into "https://api.crc.testing:6443" as "kubeadmin" using existing credentials. $ oc get users NAME UID FULL NAME IDENTITIES Pam cfe773a0-e0e2-40e1-bb5f-799db1ceaeb7 custom_htpasswd_provider:Pam developer 623cd251-b25b-44b5-a00e-67f311029588 developer:developer kubeadmin 06238f0b-4f58-45f2-9b61-94b482bb4b74 developer:kubeadmin
We can see that Pam was created and that her identity is provided by
custom_htpasswd_provider:Pam. At this point we can see that everything works. I would however advise you to test all users that you have created. This will prevent errors from showing when we want to add users to a group.
Creating groups is actually quite strait forward with the
oc adm groups command. First off, lets create a group called managers:
$ oc adm groups new managers group.user.openshift.io/managers created
And let’s add Micheal to that group:
$ oc adm groups add-users managers Michael group.user.openshift.io/managers added: "Michael"
$ oc get groups NAME USERS managers Michael
It’s that easy. We can also create a group and add users at the same time:
$ oc adm groups new sales Jim Dwight
$ oc adm groups new sales Jim Dwight group.user.openshift.io/sales created $ oc adm groups new reception Pam
oc get groups NAME USERS managers Michael reception Pam sales Jim, Dwight
It’s that easy!
Now it’s time to assign some permissions. We do this by using the
oc adm policy command. By default a user can create projects and manage objects in that project. We can assign permissions to a user or a group. We are going to give Michael full permissions to the cluster by giving him
cluster-admin cluster role:
oc adm policy add-cluster-role-to-user cluster-admin Michael clusterrole.rbac.authorization.k8s.io/cluster-admin added: "Michael"
Now we will create a project as Micheal and give the sales group permissions to it:
$ oc new-project sales $ oc adm policy add-role-to-group edit sales \ --namespace sales clusterrole.rbac.authorization.k8s.io/edit added: "sales"
Take note of the
--namespace flag in this command. This will bind the permissions to the namespace sales.
We also want to give the reception groups view permissions to the namespace sales:
$ oc adm policy add-role-to-group view reception --namespace sales clusterrole.rbac.authorization.k8s.io/view added: "reception"
To view all bound permissions to a namespace we can use:
$ oc describe rolebinding.rbac -n sale
$ oc describe rolebinding.rbac -n sales | grep reception -B 9 Name: view Labels: <none> Annotations: <none> Role: Kind: ClusterRole Name: view Subjects: Kind Name Namespace ---- ---- --------- Group reception
For a full list of roles and permissions check out the RedHat OpenShift documentation on Roles.
Optional: Removing the default kubeadmin
A great best practice is to remove the default kubeadmin user. However, we should only do this after assigning the cluster-role
cluster-admin to a user that we have testes. To make sure of this let’s check the binding:
$ oc describe rolebinding.rbac | grep ClusterRole -A 5 Kind: ClusterRole Name: admin Subjects: Kind Name Namespace ---- ---- --------- User Michael ....
Check! Now we can delete the default kubeadmin user 2 :
$ oc delete secrets kubeadmin -n kube-system secret "kubeadmin" deleted
Understanding how user creation, authentication and permissions works is a basic principle of working with cluster. Is is however often overlooked because there are so many pre configured ways out there to get this working (like integration with Azure or a direct LDPA sync). It’s important have a firm understanding of Users, Groups and Permissions in order to be proficient OpenShift Admin.
I hope this post has helped you. Check out my other EX280 related content on my EX280 page
Found this useful? Consider sponsoring me or buying me a cup of coffee at KoFi