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
Adding users
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 openshift-config:
$ 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
custom_htpasswd_provider - With the source secret
htpasswd-source
$ 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
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!
Assigning Permissions
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
For example:
$ 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
Wrapping up
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