Table of Contents

• Understanding authentication
• Users
• Groups
• Identity provider
• Configuring an HTPasswd identity provider
• Manage Users
• Manage Groups

For users to interact with OKD, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OKD API. The authorization layer then uses information about the requesting user to determine if the request is allowed.

A user in OKD is an entity that can make requests to the OKD API. An OKD user object represents an actor which can be granted permissions in the system by adding roles to them or to their groups. Typically, this represents the account of a developer or administrator that is interacting with OKD.

User Types:

Each user must authenticate in some way in order to access OKD. API requests with no authentication or invalid authentication are authenticated as requests by the anonymous system user. Once authenticated, policy determines what the user is authorized to do.

A user can be assigned to one or more groups, each of which represent a certain set of users. Groups are useful when managing authorization policies to grant permissions to multiple users at once.

In addition to explicitly defined groups, there are also system groups, or virtual groups, that are automatically provisioned by the cluster.

Most inportant default virtual groups:

To disable login for a user you can remove it from system:authenticated and system:authenticated:oauth groups

The OKD master includes a built-in OAuth server. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. As an administrator, you can configure OAuth to specify an identity provider after you install your cluster.

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

Supported identity providers

https://docs.okd.io/latest/authentication/identity_providers/configuring-htpasswd-identity-provider.html#configuring-htpasswd-identity-provider

To define an HTPasswd identity provider you must perform the following steps:

1. Create an htpasswd file to store the user and password information.
2. Create an OKD secret to represent the htpasswd file.
3. Define the HTPasswd identity provider resource.
4. Apply the resource to the default OAuth configuration.

First you must generate a flat file that contains the user names and passwords for your cluster by using htpasswd.

Man page for htpasswd

htpasswd -c -B -b </path/to/users.htpasswd> <user_name> <password>

Example:

htpasswd -c -B -b users.htpasswd user1 MyPassword!

Output should be something like this:

Adding password for user user1

Continue to add or update credentials to the file:

htpasswd -B -b </path/to/users.htpasswd> <user_name> <password>

When you have your htpasswd file, you need to create a OKD Secret resource from it for OKD to use the htpasswd identity provider. This step needs to be done every time the htpasswd file is updated in order to update the OKD Secret as well.

Create an OKD Secret that contains the HTPasswd users file:

oc create secret generic htpass-secret --from-file=htpasswd=</path/to/users.htpasswd> -n openshift-config

Next thing we need to create the Custom Resource (CR) for our new Identity Provider. Something like this: Example CR

1. Apply the defined CR:

oc apply -f </path/to/CR>

2. Log in to the cluster as a user from your identity provider:

oc login -u <username>

3. Confirm that the user logged in successfully:

oc whoami

We can't manage the htpasswd file in OKD itself. We need to extract it from Secret, modify and then replace it.

1. Confirm secret name:

oc get secret -n openshift-config

2. Retrieve htpasswd file from Secret:

oc extract secret/HTPASSWD_SECRET --to - -n openshift-config > users.htpasswd

3. Add new user:

htpasswd -b -B htpasswd <new_user_name> <password>

4. Replace Secret with our new Secret:

oc create secret generic HTPASSWD_SECRET --from-file=users.htpasswd --dry-run -o yaml -n openshift-config | oc replace -f -

5. Check identity:

oc get identity

6. Verify:

oc login -u <new_user_name>

oc whoami

It will be mostly the same process as adding a new user.

1. Confirm secret name:

oc get secret -n openshift-config

2. Retrieve htpasswd file from Secret:

oc extract secret/HTPASSWD_SECRET --to - -n openshift-config > users.htpasswd

3. Remove user:

Simply edit the file and delete the line with the username and password hash:

vim users.htpasswd

or remove with htpasswd:

htpasswd -D users.htpasswd <username>

4. Replace Secret with our new Secret:

oc create secret generic HTPASSWD_SECRET --from-file=users.htpasswd --dry-run -o yaml -n openshift-config | oc replace -f -

5. Remove user's Identity:

oc get identity

oc delete identity/HTPASSWD_PROVIDER:<username>

6. Remove user from the cluster:

oc get users

oc delete user/<username>

User needs to be removed, otherwise the user can continue using their token as long as it has not expired.

7. Wait for OAuth pod to restart then verify:

oc get users

oc get identity

oc adm groups new <group>

oc adm groups new <group> <user>

oc adm groups add-users <group> <user1> <user2>

oc adm groups remove-users <group> <user1> <user2>