In this post, we will review how to configure Kasten K10 installed via Operator for Red Hat Openshift to integrate the Authentikation of Microsoft Active Directory to access the console of K10 with Dex.

Documentation

As always, we must visit the official documentation of the solutions that we will use for this post:

• Kasten K10 https://docs.kasten.io/latest/install/openshift/operator.html
• Kasten Auth https://docs.kasten.io/latest/access/Authentikation.html
• Red Hat OpenShift https://docs.openshift.com/
• Included in Kasten, Dex https://dexidp.io/docs/

One of the integrations most used in business environments for Authentikation and centralized access is Microsoft Active Directory, with different solutions. In this case, we will review the access to the console Kasten K10 installed from the Operator with its respective “ro

When installing from the operator, changes must be made to the yaml configuration file, which can be accessed from the OpenShift console:

Active Directory Authentication Configuration

Using user groups to manage access to different platforms is always good. In this case, we will also use user groups. The first thing to create is a User Group in Active Directory with a name related to the Cluster Roles of Kasten K10:

We will add the users who need access to Kasten K10, and we will proceed to generate the Cluster Role Binding and Role Binding necessary for Kasten K10 so that users belonging to the group “k10admins”. The first ClusterRoleBinding required is the following:

kubectl create clusterrolebinding k10-ad-oc --clusterrole=k10-admin --group=k10admins

The following RoleBinding is performed on the namespace of "kasten-io” with the role of k10-ns-admin:

kubectl create rolebinding k10-ad-ns --role=k10-ns-admin \
    --namespace=kasten-io \
    --group=k10admins

With these requirements created, we will proceed to configure Kasten K10.

Configuration Kasten K10 and Microsoft Active Directory

We have to enter the configuration of the Red Hat Operator OpenShift and then, in the instance of K10 installed to access the yaml file:

Here it will be crucial that we be careful when modifying this file since if any configurations or conditions are not fulfilled, OpenShift, will reapply the previously working yaml file, and you will not see your changes reflected. Within the yaml file is an "auth" variable with its respective settings. It should be added after the last configuration or replace the entire block with:

ldap:
      enabled: true
      bindPW: 'SuperDuperPassword'
      usernameClaim: email
      groupSearch:
        baseDN: 'DC=24xsiempre,DC=cl'
        filter: (objectClass=group)
        nameAttr: cn
        userMatchers:
          - groupAttr: member
            userAttr: distinguishedName
      bindDN: 'CN=administrator,CN=Users,DC=24xsiempre,DC=cl'
      host: 'ad.24xsiempre.cl:389'
      usernamePrefix: '-'
      insecureNoSSL: true
      groupnameClaim: groups
      userSearch:
        baseDN: 'DC=24xsiempre,DC=cl'
        emailAttr: userPrincipalName
        filter: (objectClass=user)
        idAttr: sAMAccountName
        nameAttr: givenName
        username: sAMAccountName
      restartPod: false
      insecureSkipVerifySSL: true
      startTLS: false
      usernamePrompt: Email Address
      secretName: ''
      dashboardURL: 'http://k10-route-kasten-io.apps.oc.24xsiempre.cl/k10/'
      groupnamePrefix: '-'
    tokenAuth:
      enabled: false

As seen in the previous data, it is necessary to change the following variables with the data of your environment:

• bindPW | Password to Authenticate in AD or use secret
• baseDN | Domain of your environment DC=24xsiempre,DC=cl
• bindDN | User that will Authenticate in AD as service CN=administrator,CN=Users,DC=24xsiempre,DC=cl
• host | DNS or AD server IP
• baseDN | Domain of your environment DC=24xsiempre,DC=cl
• dashboardURL | The route generated in OpenShift http://k10-route-kasten-io.apps.oc.24xsiempre.cl/k10/

Then make sure to click on "Save" to validate the configuration. There can be two ways here, do a rollout restart or remove all the pods from Kasten and wait until they are all in "Running" again to eliminate all the pods from kasten-io and then auto-generate:

kubectl delete pods -all -n kasten-io

After that, access the "route" of OpenShift created and validate Authentication.

Log Review

In case of any problem with Authentication to Microsoft Active Directory, it is essential to review the "Dex" Logs, which is the interface that is connected to Active Directory, and look for the users associated with the groups that will be Authenticated in the console Kasten K10, to view the logs from the console OpenShift, you have to enter “Workloads”, “Pods”, within the project or namespace “kasten-io” and select the pod “auth-svc-“

Then click on “Logs” and finally, next to “Log Streaming” select “dex”

Search Attributes in Active Directory

If errors appear where dex or Authentication indicates that it cannot find the users or groups, it is necessary to validate the search for the attributes in the domain. One of the most used tools in Linux is "ldapsearch." For example, Ubuntu 22.04.2 is installed as follows:

sudo apt-get install ldap-utils

To then use the ldapsearch commands and correctly search for the users and groups that need to be configured in the path of “baseDN" for example with the following command, we will validate the attribute of "userPrincipalName"baseDN", for example with the following command, we will validate the attribute of "userPrincipalName"

ldapsearch -H 'ldap://20.20.20.20' -D '[email protected]' -W -b 'DC=24xsiempre,DC=cl' 'SamAccountName=veeam'

Using Secret to Authenticate with Active Directory

In the case of environments where it is not allowed to use the password directly in the yaml, it is possible to configure the password with a secret where the command to use to create the secret is the following:

kubectl create secret generic k10-ad-secret-prod --from-literal=bindPW=SuperDuperPassword -n kasten-io

Already with the password of the user that is Authenticated in Active Directory in secret, we only need to configure the yaml of the instance K10 created in Operator Kasten at Red Hat OpenShift:

ldap:
      enabled: true
      usernameClaim: email
      groupSearch:
        baseDN: 'DC=24xsiempre,DC=cl'
        filter: (objectClass=group)
        nameAttr: cn
        userMatchers:
          - groupAttr: member
            userAttr: distinguishedName
      bindDN: 'CN=administrator,CN=Users,DC=24xsiempre,DC=cl'
      host: 'ad.24xsiempre.cl:389'
      usernamePrefix: '-'
      insecureNoSSL: true
      groupnameClaim: groups
      userSearch:
        baseDN: 'DC=24xsiempre,DC=cl'
        emailAttr: userPrincipalName
        filter: (objectClass=user)
        idAttr: sAMAccountName
        nameAttr: givenName
        username: sAMAccountName
      restartPod: false
      insecureSkipVerifySSL: true
      startTLS: false
      usernamePrompt: Email Address
      secretName: ''
      dashboardURL: 'http://k10-route-kasten-io.apps.oc.24xsiempre.cl/k10/'
      groupnamePrefix: '-'
      bindPWSecretName: k10-ad-secret
    tokenAuth:
      enabled: false

In the previous configuration, the variable is observed:

• bindPWSecretName

It is associated with the secret's name that has the user's password to Authenticate.

Now all that remains is to wait for the pods to restart or delete all the pods with the command:

kubectl delete pods --all -n kasten-io

And it will be possible again to Authenticate with Active Directory and Kasten K10