Ansible Tower / AWX / Automation controller Security

Reading time: 7 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, але краще отримати іншу.