Data protection, Kubernetes, cybersecurity and AI. Hands-on guides from the trenches: Veeam, Kasten, VMware, Oracle, cloud, and whatever I’m breaking in the homelab this week.
Table of ContentsTable of Contents
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.
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:
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
```bash
The following RoleBinding is performed on the namespace of "kasten-io” with the role of k10-ns-admin:
```bash
kubectl create rolebinding k10-ad-ns --role=k10-ns-admin \
--namespace=kasten-io \
--group=k10admins
```bash
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 very important that we are careful when modifying this file, since, if any of the configuration or conditions are not met, OpenShift, it will re-apply the previously working yaml file and the changes will not be reflected. Inside the yaml file, there is an “auth” variable with its respective settings, it must be added after the last configuration or replace the entire block with:
```bash
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
```bash
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:
```bash
kubectl delete pods -all -n kasten-io
```bash
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:
```bash
sudo apt-get install ldap-utils
```text
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"
```text
ldapsearch -H 'ldap://20.20.20.20' -D '[email protected]' -W -b 'DC=24xsiempre,DC=cl' 'SamAccountName=veeam'
```bash
## 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:
```bash
kubectl create secret generic k10-ad-secret-prod --from-literal=bindPW=SuperDuperPassword -n kasten-io
```bash
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:
```bash
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
```bash
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:
```bash
kubectl delete pods --all -n kasten-io
And it will be possible again to Authenticate with Active Directory and Kasten K10
