Ansible Tower / AWX / Automation controller Security

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

Ansible Tower або його відкритий аналог AWX також відомий як інтерфейс користувача Ansible, панель управління та REST API. Завдяки контролю доступу на основі ролей, плануванню завдань та графічному управлінню інвентарем, ви можете керувати своєю інфраструктурою Ansible з сучасного інтерфейсу. REST API Tower та командний інтерфейс спрощують інтеграцію з поточними інструментами та робочими процесами.

Automation Controller є новішою версією Ansible Tower з більшою кількістю можливостей.

Differences

Згідно з цією інформацією, основні відмінності між Ansible Tower та AWX полягають у отриманій підтримці, а Ansible Tower має додаткові функції, такі як контроль доступу на основі ролей, підтримка користувацьких API та визначені користувачем робочі процеси.

Tech Stack

• Web Interface: Це графічний інтерфейс, де користувачі можуть керувати інвентарями, обліковими даними, шаблонами та завданнями. Він розроблений для інтуїтивного використання та надає візуалізації для допомоги в розумінні стану та результатів ваших автоматизаційних завдань.

• REST API: Все, що ви можете зробити в веб-інтерфейсі, ви також можете зробити через REST API. Це означає, що ви можете інтегрувати AWX/Tower з іншими системами або скриптувати дії, які ви зазвичай виконуєте в інтерфейсі.

• Database: AWX/Tower використовує базу даних (зазвичай PostgreSQL) для зберігання своєї конфігурації, результатів завдань та інших необхідних операційних даних.

• RabbitMQ: Це система обміну повідомленнями, що використовується AWX/Tower для зв'язку між різними компонентами, особливо між веб-сервісом та виконавцями завдань.

• Redis: Redis служить кешем та бекендом для черги завдань.

Logical Components

• Inventories: Інвентар є збіркою хостів (або вузлів), проти яких можуть бути виконані завдання (Ansible playbooks). AWX/Tower дозволяє вам визначати та групувати ваші інвентарі, а також підтримує динамічні інвентарі, які можуть отримувати списки хостів з інших систем таких як AWS, Azure тощо.

• Projects: Проект — це, по суті, збірка Ansible playbooks, отриманих з системи контролю версій (такої як Git), щоб отримати останні playbooks за потреби.

• Templates: Шаблони завдань визначають як буде виконано конкретний playbook, вказуючи інвентар, облікові дані та інші параметри для завдання.

• Credentials: AWX/Tower надає безпечний спосіб керувати та зберігати секрети, такі як SSH ключі, паролі та API токени. Ці облікові дані можуть бути асоційовані з шаблонами завдань, щоб playbooks мали необхідний доступ під час виконання.

• Task Engine: Тут відбувається магія. Двигун завдань побудований на Ansible і відповідає за виконання playbooks. Завдання надсилаються до двигуна завдань, який потім виконує Ansible playbooks проти призначеного інвентарю, використовуючи вказані облікові дані.

• Schedulers and Callbacks: Це розширені функції в AWX/Tower, які дозволяють планувати виконання завдань у певний час або за зовнішніми подіями.

• Notifications: AWX/Tower може надсилати сповіщення на основі успіху або невдачі завдань. Він підтримує різні засоби сповіщень, такі як електронні листи, повідомлення Slack, вебхуки тощо.

• Ansible Playbooks: Ansible playbooks є інструментами конфігурації, розгортання та оркестрації. Вони описують бажаний стан систем у автоматизованому, повторюваному вигляді. Написані в YAML, playbooks використовують декларативну мову автоматизації Ansible для опису конфігурацій, завдань та кроків, які потрібно виконати.

Job Execution Flow

1. User Interaction: Користувач може взаємодіяти з AWX/Tower через Web Interface або REST API. Ці інтерфейси надають фронтальний доступ до всіх функцій, які пропонує AWX/Tower.

2. Job Initiation:

• Користувач, через веб-інтерфейс або API, ініціює завдання на основі Job Template.

• Шаблон завдання включає посилання на Inventory, Project (що містить playbook) та Credentials.

• Після ініціації завдання запит надсилається на бекенд AWX/Tower для постановки завдання в чергу на виконання.

1. Job Queuing:

• RabbitMQ обробляє обмін повідомленнями між веб-компонентом та виконавцями завдань. Як тільки завдання ініційовано, повідомлення надсилається до двигуна завдань за допомогою RabbitMQ.

• Redis виступає як бекенд для черги завдань, керуючи чергами завдань, що чекають виконання.

1. Job Execution:

• Task Engine підбирає завдання з черги. Він отримує необхідну інформацію з Database про асоційований playbook, інвентар та облікові дані.

• Використовуючи отриманий Ansible playbook з асоційованого Project, двигун завдань виконує playbook проти вказаних Inventory вузлів, використовуючи надані Credentials.

• Під час виконання playbook його вихідні дані (журнали, факти тощо) захоплюються та зберігаються в Database.

1. Job Results:

• Як тільки playbook закінчує виконання, результати (успіх, невдача, журнали) зберігаються в Database.

• Користувачі можуть переглядати результати через веб-інтерфейс або запитувати їх через REST API.

• На основі результатів завдань, Notifications можуть бути надіслані, щоб повідомити користувачів або зовнішні системи про статус завдання. Сповіщення можуть бути електронними листами, повідомленнями Slack, вебхуками тощо.

1. External Systems Integration:

• Inventories можуть динамічно отримуватися з зовнішніх систем, що дозволяє AWX/Tower отримувати хости з джерел, таких як AWS, Azure, VMware та інших.

• Projects (playbooks) можуть бути отримані з систем контролю версій, що забезпечує використання актуальних playbooks під час виконання завдань.

• Schedulers and Callbacks можуть бути використані для інтеграції з іншими системами або інструментами, що дозволяє AWX/Tower реагувати на зовнішні тригери або виконувати завдання у визначений час.

AWX lab creation for testing

Following the docs можна використовувати docker-compose для запуску 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

Підтримувані ролі

Найбільш привілейована роль називається Системний адміністратор. Будь-хто з цією роллю може модифікувати все.

З точки зору white box security вам потрібна роль Системного аудитора, яка дозволяє переглядати всі дані системи, але не може вносити зміни. Іншою опцією було б отримати роль Аудитора організації, але краще отримати іншу.

Розгорніть це, щоб отримати детальний опис доступних ролей

1. Системний адміністратор:

• Це роль суперкористувача з дозволами на доступ і модифікацію будь-якого ресурсу в системі.

• Вони можуть керувати всіма організаціями, командами, проектами, інвентарями, шаблонами завдань тощо.

1. Системний аудитор:

• Користувачі з цією роллю можуть переглядати всі дані системи, але не можуть вносити зміни.

• Ця роль призначена для дотримання норм і контролю.

1. Ролі організації:

• Адміністратор: Повний контроль над ресурсами організації.

• Аудитор: Доступ лише для перегляду ресурсів організації.

• Член: Основне членство в організації без конкретних дозволів.

• Виконати: Може виконувати шаблони завдань в організації.

• Читати: Може переглядати ресурси організації.

1. Ролі проекту:

• Адміністратор: Може керувати і модифікувати проект.

• Використовувати: Може використовувати проект у шаблоні завдання.

• Оновити: Може оновити проект за допомогою SCM (системи контролю версій).

1. Ролі інвентарю:

• Адміністратор: Може керувати і модифікувати інвентар.

• Ad Hoc: Може виконувати ad hoc команди на інвентарі.

• Оновити: Може оновити джерело інвентарю.

• Використовувати: Може використовувати інвентар у шаблоні завдання.

• Читати: Доступ лише для перегляду.

1. Ролі шаблону завдання:

• Адміністратор: Може керувати і модифікувати шаблон завдання.

• Виконати: Може виконувати завдання.

• Читати: Доступ лише для перегляду.

1. Ролі облікових даних:

• Адміністратор: Може керувати і модифікувати облікові дані.

• Використовувати: Може використовувати облікові дані в шаблонах завдань або інших відповідних ресурсах.

• Читати: Доступ лише для перегляду.

1. Ролі команди:

• Член: Частина команди, але без конкретних дозволів.

• Адміністратор: Може керувати членами команди та пов'язаними ресурсами.

1. Ролі робочого процесу:

• Адміністратор: Може керувати і модифікувати робочий процес.

• Виконати: Може виконувати робочий процес.

• Читати: Доступ лише для перегляду.

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.