24xSiempre, Guia, Kasten, Kubernetes, Microsoft, OpenShift, RBAC, Red Hat, Respaldo, Respaldo Kubernetes, Seguridad, Veeam, vSphere CSI

Como Integrar Active Directory con Kasten K10 y OpenShift

Por Deja un Comentario

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.

Documentación

Como siempre, debemos visitar la documentación oficial de las soluciones que utilizaremos para este post:

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:

Configuración Autenticación Active Directory

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

El siguiente RoleBinding se realiza en el namespace de “kasten-io” con el rol de k10-ns-admin;

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

Ya con estos requerimientos creados procederemos a configurar Kasten K10.

Configuración Kasten K10 y Microsoft Active Directory

Solo 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:

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

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:

kubectl delete pods -all -n kasten-io

Luego de eso, acceder a la ruta de OpenShift creada y validar autenticación.

Revisión de Logs

En 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 Directory

En 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:

sudo apt-get install ldap-utils

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”

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

Usando Secret para Autenticarse con Active Directory

En 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:

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

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:

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

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:

kubectl delete pods --all -n kasten-io

Y sera posible nuevamente autenticarse con Active Directory y Kasten K10

Post Views: 27
 

Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *