Ansible Tower / AWX / Automation controller Security

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

• Si deseas ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF ¡Consulta los PLANES DE SUSCRIPCIÓN!

• Obtén el oficial PEASS & HackTricks swag

• Descubre The PEASS Family, nuestra colección exclusiva de NFTs

• Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @hacktricks_live.

• Comparte tus trucos de hacking enviando PRs a los repositorios de HackTricks y HackTricks Cloud.

Información Básica

Ansible Tower o su versión de código abierto AWX también se conoce como la interfaz de usuario, panel de control y API REST de Ansible. Con control de acceso basado en roles, programación de trabajos y gestión gráfica de inventarios, puedes administrar tu infraestructura de Ansible desde una interfaz moderna. La API REST y la interfaz de línea de comandos de Tower facilitan su integración en herramientas y flujos de trabajo actuales.

Automation Controller es una versión más reciente de Ansible Tower con más capacidades.

Diferencias

Según esto, las principales diferencias entre Ansible Tower y AWX son el soporte recibido y que Ansible Tower tiene características adicionales como control de acceso basado en roles, soporte para APIs personalizadas y flujos de trabajo definidos por el usuario.

Pila Tecnológica

• Interfaz Web: Esta es la interfaz gráfica donde los usuarios pueden gestionar inventarios, credenciales, plantillas y trabajos. Está diseñada para ser intuitiva y proporciona visualizaciones para ayudar a comprender el estado y los resultados de tus trabajos de automatización.

• API REST: Todo lo que se puede hacer en la interfaz web, también se puede hacer a través de la API REST. Esto significa que puedes integrar AWX/Tower con otros sistemas o automatizar acciones que normalmente realizarías en la interfaz.

• Base de Datos: AWX/Tower utiliza una base de datos (típicamente PostgreSQL) para almacenar su configuración, resultados de trabajos y otros datos operativos necesarios.

• RabbitMQ: Este es el sistema de mensajería utilizado por AWX/Tower para comunicarse entre los diferentes componentes, especialmente entre el servicio web y los ejecutores de tareas.

• Redis: Redis sirve como caché y backend para la cola de tareas.

Componentes Lógicos

• Inventarios: Un inventario es una colección de hosts (o nodos) contra los cuales se pueden ejecutar trabajos (playbooks de Ansible). AWX/Tower te permite definir y agrupar tus inventarios y también admite inventarios dinámicos que pueden obtener listas de hosts de otros sistemas como AWS, Azure, etc.

• Proyectos: Un proyecto es esencialmente una colección de playbooks de Ansible obtenidos de un sistema de control de versiones (como Git) para extraer los playbooks más recientes cuando sea necesario.

• Plantillas: Las plantillas de trabajo definen cómo se ejecutará un playbook en particular, especificando el inventario, las credenciales y otros parámetros para el trabajo.

• Credenciales: AWX/Tower proporciona una forma segura de gestionar y almacenar secretos, como claves SSH, contraseñas y tokens de API. Estas credenciales pueden asociarse con plantillas de trabajo para que los playbooks tengan el acceso necesario cuando se ejecutan.

• Motor de Tareas: Aquí es donde sucede la magia. El motor de tareas está construido en Ansible y es responsable de ejecutar los playbooks. Los trabajos se envían al motor de tareas, que luego ejecuta los playbooks de Ansible contra el inventario designado utilizando las credenciales especificadas.

• Planificadores y Devoluciones de Llamada: Estas son características avanzadas en AWX/Tower que permiten programar trabajos para que se ejecuten en momentos específicos o se activen por eventos externos.

• Notificaciones: AWX/Tower puede enviar notificaciones basadas en el éxito o fracaso de los trabajos. Admite varios medios de notificación como correos electrónicos, mensajes de Slack, webhooks, etc.

• Playbooks de Ansible: Los playbooks de Ansible son herramientas de configuración, implementación y orquestación. Describen el estado deseado de los sistemas de forma automatizada y repetible. Escritos en YAML, los playbooks utilizan el lenguaje de automatización declarativo de Ansible para describir configuraciones, tareas y pasos que deben ejecutarse.

Flujo de Ejecución de Trabajos

1. Interacción del Usuario: Un usuario puede interactuar con AWX/Tower a través de la Interfaz Web o la API REST. Estas proporcionan acceso frontal a todas las funcionalidades ofrecidas por AWX/Tower.

2. Inicio del Trabajo:

• El usuario, a través de la Interfaz Web o la API, inicia un trabajo basado en una Plantilla de Trabajo.

• La Plantilla de Trabajo incluye referencias al Inventario, Proyecto (que contiene el playbook) y Credenciales.

• Al iniciar el trabajo, se envía una solicitud al backend de AWX/Tower para encolar el trabajo para su ejecución.

3. Cola de Trabajos:

• RabbitMQ maneja la mensajería entre el componente web y los ejecutores de tareas. Una vez que se inicia un trabajo, se envía un mensaje al motor de tareas utilizando RabbitMQ.

• Redis actúa como backend para la cola de tareas, gestionando trabajos en cola esperando ser ejecutados.

4. Ejecución del Trabajo:

• El Motor de Tareas recoge el trabajo en cola. Recupera la información necesaria de la Base de Datos sobre el playbook asociado al trabajo, el inventario y las credenciales.

• Utilizando el playbook de Ansible recuperado del Proyecto asociado, el Motor de Tareas ejecuta el playbook contra los nodos del Inventario especificado utilizando las Credenciales proporcionadas.

• A medida que se ejecuta el playbook, su salida de ejecución (logs, hechos, etc.) se captura y almacena en la Base de Datos.

5. Resultados del Trabajo:

• Una vez que el playbook termina de ejecutarse, los resultados (éxito, fracaso, logs) se guardan en la Base de Datos.

• Los usuarios pueden ver los resultados a través de la Interfaz Web o consultarlos a través de la API REST.

• Según los resultados del trabajo, se pueden enviar Notificaciones para informar a los usuarios o sistemas externos sobre el estado del trabajo. Las notificaciones pueden ser correos electrónicos, mensajes de Slack, webhooks, etc.

6. Integración con Sistemas Externos:

• Los Inventarios pueden obtenerse dinámicamente de sistemas externos, lo que permite a AWX/Tower extraer hosts de fuentes como AWS, Azure, VMware, y más.

• Los Proyectos (playbooks) pueden obtenerse de sistemas de control de versiones, asegurando el uso de playbooks actualizados durante la ejecución de trabajos.

• Los Planificadores y Devoluciones de Llamada se pueden utilizar para integrarse con otros sistemas o herramientas, haciendo que AWX/Tower reaccione a disparadores externos o ejecute trabajos en momentos predeterminados.

Creación de laboratorio AWX para pruebas

Siguiendo la documentación es posible utilizar docker-compose para ejecutar AWX:

git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version

cd awx

# Build
make docker-compose-build

# Run
make docker-compose

# Or to create a more complex env
MAIN_NODE_TYPE=control EXECUTION_NODE_COUNT=2 COMPOSE_TAG=devel make docker-compose

# Clean and build the UI
docker exec tools_awx_1 make clean-ui ui-devel

# Once migrations are completed and the UI is built, you can begin using AWX. The UI can be reached in your browser at https://localhost:8043/#/home, and the API can be found at https://localhost:8043/api/v2.

# Create an admin user
docker exec -ti tools_awx_1 awx-manage createsuperuser

# Load demo data
docker exec tools_awx_1 awx-manage create_preload_data

RBAC

Roles compatibles

El rol más privilegiado se llama Administrador del Sistema. Cualquier persona con este rol puede modificar cualquier cosa.

Desde una revisión de seguridad de caja blanca, necesitarías el rol de Auditor del Sistema, que permite ver todos los datos del sistema pero no puede realizar cambios. Otra opción sería obtener el rol de Auditor de la Organización, pero sería mejor obtener el otro.

Expande esto para obtener una descripción detallada de los roles disponibles

1. Administrador del Sistema:

• Este es el rol de superusuario con permisos para acceder y modificar cualquier recurso en el sistema.

• Pueden gestionar todas las organizaciones, equipos, proyectos, inventarios, plantillas de trabajo, etc.

2. Auditor del Sistema:

• Los usuarios con este rol pueden ver todos los datos del sistema pero no pueden realizar cambios.

• Este rol está diseñado para cumplimiento y supervisión.

3. Roles de la Organización:

• Admin: Control total sobre los recursos de la organización.

• Auditor: Acceso de solo lectura a los recursos de la organización.

• Miembro: Membresía básica en una organización sin permisos específicos.

• Ejecutar: Puede ejecutar plantillas de trabajo dentro de la organización.

• Leer: Puede ver los recursos de la organización.

4. Roles de Proyecto:

• Admin: Puede gestionar y modificar el proyecto.

• Usar: Puede usar el proyecto en una plantilla de trabajo.

• Actualizar: Puede actualizar el proyecto utilizando SCM (control de fuente).

5. Roles de Inventario:

• Admin: Puede gestionar y modificar el inventario.

• Ad Hoc: Puede ejecutar comandos ad hoc en el inventario.

• Actualizar: Puede actualizar la fuente del inventario.

• Usar: Puede usar el inventario en una plantilla de trabajo.

• Leer: Acceso de solo lectura.

6. Roles de Plantilla de Trabajo:

• Admin: Puede gestionar y modificar la plantilla de trabajo.

• Ejecutar: Puede ejecutar el trabajo.

• Leer: Acceso de solo lectura.

7. Roles de Credenciales:

• Admin: Puede gestionar y modificar las credenciales.

• Usar: Puede usar las credenciales en plantillas de trabajo u otros recursos relevantes.

• Leer: Acceso de solo lectura.

8. Roles de Equipo:

• Miembro: Parte del equipo pero sin permisos específicos.

• Admin: Puede gestionar los miembros del equipo y los recursos asociados.

9. Roles de Flujo de Trabajo:

• Admin: Puede gestionar y modificar el flujo de trabajo.

• Ejecutar: Puede ejecutar el flujo de trabajo.

• Leer: Acceso de solo lectura.