Data protection, Kubernetes, ciberseguridad e IA. Guías prácticas desde la trinchera: Veeam, Kasten, VMware, Oracle, cloud y lo que sea que esté rompiendo en el homelab esta semana.
Tabla de contenidoTabla de contenido
En este post, revisaremos como realizar la configuración de Kasten K10 instalado a través del Operador para Red Hat Openshift con el objetivo de integrar la autenticación de Microsoft Active Directory para acceder a la consola de K10 con Dex.
Una de las integraciones más utilizadas en entornos empresariales para la autenticación y acceso centralizado es Microsoft Active Directory con distintas soluciones. En este caso revisaremos el acceso a la consola de Kasten K10 instalado desde el Operador con su respectiva “route”.
Al ser instalado desde el operador, los cambios deben ser realizados en el archivo de configuración yaml que se puede acceder desde la consola de Openshift:
Siempre es bueno usar grupos de usuarios para la gestión de acceso a diferentes plataformas, en este caso, también utilizaremos grupos de usuarios, lo primero a crear es un Grupo de Usuarios en Active Directory con un nombre relacionados los Cluster Roles de Kasten K10:
Agregaremos los usuarios que necesiten acceso a Kasten K10 y procederemos a generar los Cluster Role Binding y Role Binding necesario por Kasten K10 para que se puedan autenticar los usuarios pertenecientes al grupo “k10admins”. El primer ClusterRoleBinding necesario es el siguiente:
kubectl create clusterrolebinding k10-ad-oc --clusterrole=k10-admin --group=k10admins
```bash
El siguiente RoleBinding se realiza en el namespace de "kasten-io" con el rol de k10-ns-admin;
```bash
kubectl create rolebinding k10-ad-ns --role=k10-ns-admin \
--namespace=kasten-io \
--group=k10admins
```bash
Ya con estos requerimientos creados procederemos a configurar Kasten K10.
## Configuración Kasten K10 y Microsoft Active DirectorySolo debemos entrar en la configuración del Operador de Red Hat OpenShift y luego en la instancia de K10 instalada para acceder al archivo yaml:
Aqui será muy importante que seamos cuidadosos al modificar este archivo, ya que, si alguna de las configuración o condiciones no se cumple, OpenShift, volverá a aplicar el archivo yaml que funcionaba correctamente anteriormente y no se verán los cambios reflejados. Dentro del archivo yaml, existe una variable "auth" con sus respectivas configuraciones, se debe agregar después de la última configuración o reemplazar el bloque completo con:
```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
Como se observa en los datos anteriores, es necesario cambiar las siguientes varibales con los datos de tu entorno:
- bindPW \| Con la contraseña para autenticarse en AD o utilizar secret
- baseDN \| Con el dominio de tu entorno DC=24xsiempre,DC=cl
- bindDN \| Con el usuario que se autenticara en AD como servicio CN=administrator,CN=Users,DC=24xsiempre,DC=cl
- host \| DNS o IP de servidor AD
- baseDN \| Con el dominio de tu entorno DC=24xsiempre,DC=cl
- dashboardURL \| La ruta generada en OpenShift http://k10-route-kasten-io.apps.oc.24xsiempre.cl/k10/
Luego asegurarse de hacer clic en "Save" para luego validar la configuración. Aqui pueden ser dos formas, hacer un rollout restart o simplemente eliminar todos los pods de kasten y esperar que esten todos nuevamente en "Running", para eliminar todos los pods de kasten-io y luego se generen automáticamente:
```bash
kubectl delete pods -all -n kasten-io
```bash
Luego de eso, acceder a la ruta de OpenShift creada y validar autenticación.
## Revisión de LogsEn caso de algún problema con la autenticación hacia Microsoft Active Directory, es importante revisar los Logs de "Dex", el cual es la interfaz que se conecta a Active Directory y busca los usuario asociados a los grupos que se autenticarán en la consola de Kasten K10, para ver los logs desde la consola de OpenShift, solo hay que entrar en "Workloads", "Pods", dentro del proyecto o namespace "kasten-io" y seleccionar el pod "auth-svc-"Luego clic en "Logs" y por último, al lado de "Log Streaming" seleccionar "dex"## Búsqueda Atributos en Active DirectoryEn caso de que aparezcan errores donde dex o la autenticación indique que no puede encontrar los usuario o grupos, es necesario validar la búsqueda de los atributos en el dominio, una de las herramientas más usadas en linux es "ldapsearch", por ejemplo, en Ubuntu 22.04.2 se instala de la siguiente forma:
```bash
sudo apt-get install ldap-utils
```text
Para luego utilizar los comandos de ldapsearch y buscar correctamente los usuarios y grupos que necesitan ser configurados en la ruta de " **baseDN**", por ejemplo con el siguiente comando, validaremos el atributo de "userPrincipalName"```text
ldapsearch -H 'ldap://20.20.20.20' -D '[email protected]' -W -b 'DC=24xsiempre,DC=cl''SamAccountName=veeam'```bash
## Usando Secret para Autenticarse con Active DirectoryEn caso de entornos donde no se permita utilizar la contraseña directamente en los yaml, es posible configurar la contraseña con un secret donde el comando a utilizar para la creacion del secret es el siguiente:
```bash
kubectl create secret generic k10-ad-secret-prod --from-literal=bindPW=SuperDuperPassword -n kasten-io
```bash
Ya con la contraseña del usuario que se autenticada en Active Directory en el secret, solo nos falta configurar el yaml de la instancia K10 creada en el Operador de Kasten en 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
En la configuracion anterior se observa la variable:
- bindPWSecretName
Asociada con el nombre del secret que posee la contraseña del usuario para autenticarse.
Ahora solo falta esperar que se reinicen los pods o eliminar todos los pods con el comando:
```bash
kubectl delete pods --all -n kasten-io
Y sera posible nuevamente autenticarse con Active Directory y Kasten K10