Ansible Tower / AWX / Automation controller Security

Reading time: 10 minutes

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 для постановки завдання в чергу на виконання.

3. Job Queuing:

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

4. Job Execution:

• Task Engine підбирає завдання з черги. Він отримує необхідну інформацію з Database про асоційований playbook, інвентар та облікові дані.
• Використовуючи отриманий Ansible playbook з асоційованого Project, двигун завдань виконує playbook проти вказаних Inventory вузлів, використовуючи надані Credentials.
• Під час виконання playbook його вихідні дані (журнали, факти тощо) захоплюються та зберігаються в Database.

5. Job Results:

• Як тільки playbook закінчує виконання, результати (успіх, невдача, журнали) зберігаються в Database.
• Користувачі можуть переглядати результати через веб-інтерфейс або запитувати їх через REST API.
• На основі результатів завдань Notifications можуть бути надіслані, щоб повідомити користувачів або зовнішні системи про статус завдання. Сповіщення можуть бути електронними листами, повідомленнями Slack, вебхуками тощо.

6. 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

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

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

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

Enumeration & Attack-Path Mapping with AnsibleHound

AnsibleHound - це відкритий колектор BloodHound OpenGraph, написаний на Go, який перетворює read-only токен API Ansible Tower/AWX/Automation Controller на повну графіку дозволів, готову до аналізу в BloodHound (або BloodHound Enterprise).

Чому це корисно?

1. REST API Tower/AWX надзвичайно багатий і відкриває кожен об'єкт і відносини RBAC, про які знає ваша інстанція.
2. Навіть з найнижчим привілеєм (Read) токеном можливо рекурсивно перерахувати всі доступні ресурси (організації, інвентарі, хости, облікові дані, проекти, шаблони завдань, користувачі, команди…).
3. Коли сирі дані перетворюються на схему BloodHound, ви отримуєте ті ж можливості візуалізації attack-path, які так популярні в оцінках Active Directory – але тепер спрямовані на вашу CI/CD інфраструктуру.

Команди безпеки (і атакуючі!) можуть, отже:

• Швидко зрозуміти хто може стати адміністратором чого.
• Визначити облікові дані або хости, які доступні з непривабливого облікового запису.
• Поєднувати кілька “Read ➜ Use ➜ Execute ➜ Admin” зв'язків, щоб отримати повний контроль над інстанцією Tower або підлеглою інфраструктурою.

Передумови

• Ansible Tower / AWX / Automation Controller, доступний через HTTPS.
• Токен API користувача, обмежений лише Read (створений з User Details → Tokens → Create Token → scope = Read).
• Go ≥ 1.20 для компіляції колектора (або використовуйте попередньо зібрані бінарні файли).

Будівництво та запуск

# Compile the collector
cd collector
go build . -o build/ansiblehound

# Execute against the target instance
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"

Внутрішньо AnsibleHound виконує пагіновані GET запити до (принаймні) наступних кінцевих точок і автоматично слідує за related посиланнями, які повертаються в кожному JSON об'єкті:

/api/v2/organizations/
/api/v2/inventories/
/api/v2/hosts/
/api/v2/job_templates/
/api/v2/projects/
/api/v2/credentials/
/api/v2/users/
/api/v2/teams/

Всі зібрані сторінки об'єднуються в один файл JSON на диску (за замовчуванням: ansiblehound-output.json).

Перетворення BloodHound

Сирі дані Tower потім перетворюються в BloodHound OpenGraph за допомогою користувацьких вузлів, що починаються з AT (Ansible Tower):

• ATOrganization, ATInventory, ATHost, ATJobTemplate, ATProject, ATCredential, ATUser, ATTeam

А також ребра, що моделюють відносини / привілеї:

• ATContains, ATUses, ATExecute, ATRead, ATAdmin

Результат можна імпортувати безпосередньо в BloodHound:

neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json

Опційно ви можете завантажити кастомні іконки, щоб нові типи вузлів були візуально відмінними:

python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"

Захисні та наступальні міркування

• Токен Read зазвичай вважається безпечним, але все ще витікає повна топологія та всі метадані облікових даних. Ставтеся до нього як до чутливого!
• Застосовуйте найменші привілеї та обертайте / відкликайте невикористовувані токени.
• Моніторте API на предмет надмірної енумерації (багато послідовних GET запитів, висока активність пагінації).
• З точки зору атакуючого це ідеальна техніка початкового закріплення → ескалації привілеїв всередині CI/CD конвеєра.

Посилання

• AnsibleHound – BloodHound Collector for Ansible Tower/AWX
• BloodHound OSS