Uso de Kerberos para Windows en Ansible Automation Platform 2

Kerberos suele ser el método de autenticación preferido para gestionar los servidores de Windows en un entorno de dominio. Desde hace varios años, Red Hat Ansible Automation Platform permite que los clientes aprovechen este tipo de autenticación. Entonces, ¿por qué volvemos a abordar este tema? 

Ansible Automation Platform 2 se lanzó en julio de 2021, y se modificó enormemente la arquitectura de la plataforma. Uno de los cambios más importantes fue la introducción de entornos de ejecución de automatización : el uso de contenedores para empaquetar, distribuir y ejecutar los playbooks de Ansible de manera uniforme. Sin entrar en detalles, los entornos de ejecución de automatización son una imagen base de Red Hat Enterprise Linux, Ansible Core y las dependencias necesarias para ejecutar la automatización de Ansible; por lo general, son conjuntos de Ansible Content Collection y bibliotecas de Python. 

Al realizar el traslado a los contenedores, debemos tener en cuenta que veces el host localhost es un contenedor. Hay una excelente publicación del blog en la que se abarca la forma en la que localhost no es lo que parece cuando se trata de entornos de ejecución de automatización.

Con toda esta información en mente, veamos un ejemplo guiado sobre la manera de configurar la autenticación de Kerberos en Ansible Automation Platform 2, probar la configuración y establecer el controlador de automatización para usar Kerberos.

Ejemplo de configuración

Para usar Kerberos con Ansible, necesitaremos un archivo de configuración. El contenido del archivo variará según ciertos factores, como la configuración de DNS, la detección de los KDC y la cantidad de dominios. En este ejemplo, tenemos un solo dominio, DEMOLAB.LOCAL, que nuestro servidor de controlador de automatización no detecta.

Esta es la configuración de cliente de Kerberos. Hay un ejemplo similar en la guía Automation Controller Administration Guide.

[libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 }

Ahora debemos tener en cuenta los entornos de ejecución de automatización y recordar que localhost no es lo que parece. Cuando el controlador de automatización ejecuta un playbook de Ansible, activa una imagen de contenedor que no tendrá acceso al sistema de archivos fundamental del nodo del controlador. Necesitamos comprobar que el entorno de ejecución tenga acceso a la configuración de cliente de Kerberos. Tenemos dos opciones para lograrlo.

1. Asignamos la configuración de cliente de Kerberos al entorno en ejecución desde el controlador de automatización.
2. Personalizamos y diseñamos nuestro propio entorno de ejecución con Ansible Builder y agregamos el archivo krb5.conf a la imagen.

Para este ejemplo, asignaré la configuración de cliente de Kerberos al entorno en ejecución, ya que no necesito realizar ningún otro cambio. 

Para ello, debemos escribir la configuración en el directorio de configuración de cliente de Kerberos que está en el servidor de controlador de automatización denominado /etc/krb5.conf.d/DEMOLAB.LOCAL.conf

# cat /etc/krb5.conf.d/DEMOLAB.LOCAL.conf 

[libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 }   

Pruebas desde la línea de comandos

Estamos listos para comprobar la configuración desde la línea de comandos. Primero, confirmemos cuáles son los entornos de ejecución que tenemos disponibles para realizar pruebas. En el servidor del controlador de automatización, podemos cambiar al usuario awx y enumerar las imágenes del entorno de ejecución. Aquí se puede ver que el entorno de ejecución ee-supported-rhel8, que es la imagen que quiero probar, está disponible.

$ su - awx 
$ podman images 
REPOSITORY                                                         TAG     IMAGE ID   CREATED   SIZE 
registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8  latest   024856bccc5f  4 weeks ago  1.66 GB

Si necesitas realizar la prueba con otra imagen, usa el comando "podman pull" para copiar la adecuada de un registro de contenedores.

Ahora es el momento de comprobar si podemos asignar el directorio de configuración al entorno de ejecución, llevar a cabo la autenticación y obtener un ticket de Kerberos. El siguiente comando de Podman iniciará nuestro contenedor de entorno de ejecución y le asignará el directorio /etc/krb5.conf.d/. También se nos proporcionará un shell interactivo dentro del contenedor para que podamos probar el comando kinit. Es importante destacar que Kerberos usa una caché de credenciales para alojar las que sean válidas. De nuevo, recuerda que localhost no es lo que parece, por lo que no tenemos acceso al sistema de archivos ni a la caché de Kerberos. Crearemos una caché de credenciales de Kerberos temporal que nos permita probar la configuración estableciendo la variable KRB5CCNAME. El plugin de conexión WinRM usa un mecanismo similar. 

$ podman run --rm  -v "/etc/krb5.conf.d:/etc/krb5.conf.d:O" -it registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8:latest /bin/bash 

bash-4.4# export KRB5CCNAME=`mktemp` 
bash-4.4# echo $KRB5CCNAME 
/tmp/tmp.ZzBXbtGiV1 
bash-4.4# kinit svc-ansible@DEMOLAB.LOCAL 
Password for svc-ansible@DEMOLAB.LOCAL: 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.ZzBXbtGiV1 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
04/04/23 14:01:37  04/05/23 00:01:37  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 04/11/23 14:01:33

Como prueba adicional, podemos confirmar si el ticket funciona para la autenticación en un servidor específico. Después de ejecutar el comando kinit con éxito en el entorno de ejecución, podemos usar kvno para realizar la autenticación con un host de destino. En este ejemplo, verificaremos que podamos usar el ticket para llevar a cabo este proceso con windows2.demolab.local.

bash-4.4# kvno http/windows2.demolab.local 
http/windows2.demolab.local@DEMOLAB.LOCAL: kvno = 1 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.pe2PBReLm5 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
05/10/23 15:26:35  05/11/23 01:26:35  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:33 
05/10/23 15:26:49  05/11/23 01:26:35  http/windows2.demolab.local@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:3

La prueba salió bien. Es hora de pasar la configuración al controlador de automatización. 

Configuración del controlador de automatización

Necesitamos agregar una credencial de máquina en el controlador de automatización para nuestra cuenta de Windows. Debe ser el nombre principal del usuario (UPN) con el formato "nombredeusuario@DOMINIO.COM". Para agregar una credencial en el controlador de automatización, dirígete a Credentials en el menú de la izquierda, presiona Add y selecciona Machine como el tipo de credencial. Luego, ingresa el usuario y la contraseña del dominio como se muestra a continuación:

Después, podemos asignar la configuración del cliente de Kerberos al entorno de ejecución. Un administrador deberá realizar la configuración en Settings>, Job Settings  y editar la sección "Paths to expose to isolated jobs" agregando el directorio de Kerberos. Ten en cuenta que este es el mismo formato que usamos cuando llevamos a cabo una prueba desde la CLI. La configuración nueva debería verse así:

Es momento de realizar la prueba. Podemos usar un sencillo "ping" del playbook para confirmar la configuración, También podemos aumentar la cantidad de información que se guarda en el registro para incluir mensajes sobre la conexión de WinRM. Edita la plantilla de tareas y establece la cantidad de detalles en nivel 5.

Cuando iniciemos la plantilla, deberíamos ver los mensajes de conexión detallados.

Se puede observar que se creó la caché de credenciales de Kerberos temporal, la cuenta se pudo autenticar y obtuvimos un ticket. El playbook debería completarse con éxito.

Solución de problemas

Es posible que encuentres algunos mensajes de error al configurar Kerberos dentro de un entorno de ejecución. Estos son algunos de los que podrías ver y sus posibles soluciones.

• Included profile directory could not be read while initializing Kerberos 5 library: esto podría indicar que hay un archivo de configuración en el directorio /etc/krb5.conf.d que intenta incluir otros a los cuales el entorno de ejecución no tiene acceso. Verifica todos los archivos en /etc/krb5.conf.d que puedan tener una opción includedir.
• Invalid UID in persistent keyring name while getting default ccache: recuerda establecer un directorio de caché de credenciales temporal como se explicó anteriormente.
• Cannot find KDC for realm "<DOMAIN>" while getting initial credentials:  puede haber muchas razones para este error. Verifica que la configuración de Kerberos sea correcta y que aparezca un KDC válido. Si te basas en DNS para buscar los KDC, asegúrate de que el parámetro dns_lookup_kdc esté establecido en true. 
• Server not found in Kerberos database: a menudo, esto puede estar relacionado con problemas de DNS o un inventario de Ansible que no se configuró correctamente. Verifica que el nombre del host en el inventario coincida con el nombre del servidor en DNS. Además, debes confirmar que Ansible esté intentando conectarse al host mediante el nombre de dominio completamente calificado (FQDN) usando los registros de depuración de WinRM. Este es un ejemplo en el que la variable ansible_host está configurada para un servidor de Windows y estamos intentando conectarnos a la IP en lugar del nombre de host.

Siguientes pasos

Esperamos que este ejemplo haya sido útil para comprender algunos de los cambios en Ansible Automation Platform 2 y para comenzar con la autenticación de Kerberos para administrar los servidores de Windows. Windows sigue siendo muy importante para Ansible y hay más recursos disponibles para ayudarte en tu proceso.

• Ansible para Windows: aprende a utilizar Ansible para gestionar la infraestructura de Windows y los casos prácticos comunes.
• Suscripción de prueba: ¿estás listo para comenzar? Adquiere una suscripción de prueba para obtener acceso ilimitado a todos los elementos de Ansible Automation Platform.