Español - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Ansible Tower / AWX / Automation controller Security

Apoya a HackTricks

Información Básica

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

El Controlador de Automatización es una versión más nueva 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.

Stack Tecnológico

  • 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 entender el estado y los resultados de tus trabajos de automatización.

  • API REST: Todo lo que puedes hacer en la interfaz web, también puedes hacerlo a través de la API REST. Esto significa que puedes integrar AWX/Tower con otros sistemas o script 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 soporta 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 provenientes de un sistema de control de versiones (como Git) para obtener los últimos playbooks cuando sea necesario.

  • Plantillas: Las plantillas de trabajo definen cómo se ejecutará un playbook en particular, especificando el inventario, 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 ejecuten.

  • Motor de Tareas: Aquí es donde ocurre la magia. El motor de tareas está construido sobre 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.

  • Programadores y Callbacks: Estas son características avanzadas en AWX/Tower que permiten programar trabajos para que se ejecuten en momentos específicos o sean activados por eventos externos.

  • Notificaciones: AWX/Tower puede enviar notificaciones basadas en el éxito o fracaso de los trabajos. Soporta 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 manera automatizada y repetible. Escritos en YAML, los playbooks utilizan el lenguaje de automatización declarativa 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 ya sea 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 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 poner en cola el trabajo para su ejecución.

  1. 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 el backend para la cola de tareas, gestionando los trabajos en cola que esperan ejecución.

  1. 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, inventario y credenciales.

  • Usando 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 (registros, hechos, etc.) se captura y almacena en la Base de Datos.

  1. Resultados del Trabajo:

  • Una vez que el playbook termina de ejecutarse, los resultados (éxito, fracaso, registros) 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.

  1. Integración con Sistemas Externos:

  • Inventarios pueden ser obtenidos dinámicamente de sistemas externos, permitiendo que AWX/Tower obtenga hosts de fuentes como AWS, Azure, VMware y más.

  • Proyectos (playbooks) pueden ser obtenidos de sistemas de control de versiones, asegurando el uso de playbooks actualizados durante la ejecución del trabajo.

  • Programadores y Callbacks pueden ser utilizados 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 usar 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 soportados

El rol más privilegiado se llama Administrador del Sistema. Cualquiera 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 hacer ningún cambio. 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.

  1. Auditor del Sistema:

  • Los usuarios con este rol pueden ver todos los datos del sistema pero no pueden hacer ningún cambio.

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

  1. Roles de Organización:

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

  • Auditor: Acceso solo de 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.

  1. 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 usando SCM (control de versiones).

  1. 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 solo de lectura.

  1. Roles de Plantilla de Trabajo:

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

  • Ejecutar: Puede ejecutar el trabajo.

  • Leer: Acceso solo de lectura.

  1. 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 solo de lectura.

  1. Roles de Equipo:

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

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

  1. Roles de Flujo de Trabajo:

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

  • Ejecutar: Puede ejecutar el flujo de trabajo.

  • Leer: Acceso solo de lectura.

Support HackTricks
PreviousSupabase SecurityNextTODO

Last updated