Ansible Tower / AWX / Automation controller Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ansible Tower or it's opensource version AWX is also known as Ansible’s user interface, dashboard, and REST API. With role-based access control, job scheduling, and graphical inventory management, you can manage your Ansible infrastructure from a modern UI. Tower’s REST API and command-line interface make it simple to integrate it into current tools and workflows.
Automation Controller is a newer version of Ansible Tower with more capabilities.
According to this, the main differences between Ansible Tower and AWX is the received support and the Ansible Tower has additional features such as role-based access control, support for custom APIs, and user-defined workflows.
Web Interface: This is the graphical interface where users can manage inventories, credentials, templates, and jobs. It's designed to be intuitive and provides visualizations to help with understanding the state and results of your automation jobs.
REST API: Everything you can do in the web interface, you can also do via the REST API. This means you can integrate AWX/Tower with other systems or script actions that you'd typically perform in the interface.
Database: AWX/Tower uses a database (typically PostgreSQL) to store its configuration, job results, and other necessary operational data.
RabbitMQ: This is the messaging system used by AWX/Tower to communicate between the different components, especially between the web service and the task runners.
Redis: Redis serves as a cache and a backend for the task queue.
Inventories: An inventory is a collection of hosts (or nodes) against which jobs (Ansible playbooks) can be run. AWX/Tower allows you to define and group your inventories and also supports dynamic inventories which can fetch host lists from other systems like AWS, Azure, etc.
Projects: A project is essentially a collection of Ansible playbooks sourced from a version control system (like Git) to pull the latest playbooks when needed..
Templates: Job templates define how a particular playbook will be run, specifying the inventory, credentials, and other parameters for the job.
Credentials: AWX/Tower provides a secure way to manage and store secrets, such as SSH keys, passwords, and API tokens. These credentials can be associated with job templates so that playbooks have the necessary access when they run.
Task Engine: This is where the magic happens. The task engine is built on Ansible and is responsible for running the playbooks. Jobs are dispatched to the task engine, which then runs the Ansible playbooks against the designated inventory using the specified credentials.
Schedulers and Callbacks: These are advanced features in AWX/Tower that allow jobs to be scheduled to run at specific times or triggered by external events.
Notifications: AWX/Tower can send notifications based on the success or failure of jobs. It supports various means of notifications such as emails, Slack messages, webhooks, etc.
Ansible Playbooks: Ansible playbooks are configuration, deployment, and orchestration tools. They describe the desired state of systems in an automated, repeatable way. Written in YAML, playbooks use Ansible's declarative automation language to describe configurations, tasks, and steps that need to be executed.
User Interaction: A user can interact with AWX/Tower either through the Web Interface or the REST API. These provide front-end access to all the functionalities offered by AWX/Tower.
Job Initiation:
The user, via the Web Interface or API, initiates a job based on a Job Template.
The Job Template includes references to the Inventory, Project (containing the playbook), and Credentials.
Upon job initiation, a request is sent to the AWX/Tower backend to queue the job for execution.
Job Queuing:
RabbitMQ handles the messaging between the web component and the task runners. Once a job is initiated, a message is dispatched to the task engine using RabbitMQ.
Redis acts as the backend for the task queue, managing queued jobs awaiting execution.
Job Execution:
The Task Engine picks up the queued job. It retrieves the necessary information from the Database about the job's associated playbook, inventory, and credentials.
Using the retrieved Ansible playbook from the associated Project, the Task Engine runs the playbook against the specified Inventory nodes using the provided Credentials.
As the playbook runs, its execution output (logs, facts, etc.) gets captured and stored in the Database.
Job Results:
Once the playbook finishes running, the results (success, failure, logs) are saved to the Database.
Users can then view the results through the Web Interface or query them via the REST API.
Based on job outcomes, Notifications can be dispatched to inform users or external systems about the job's status. Notifications could be emails, Slack messages, webhooks, etc.
External Systems Integration:
Inventories can be dynamically sourced from external systems, allowing AWX/Tower to pull in hosts from sources like AWS, Azure, VMware, and more.
Projects (playbooks) can be fetched from version control systems, ensuring the use of up-to-date playbooks during job execution.
Schedulers and Callbacks can be used to integrate with other systems or tools, making AWX/Tower react to external triggers or run jobs at predetermined times.
Following the docs it's possible to use docker-compose to run AWX:
The most privileged role is called System Administrator. Anyone with this role can modify anything.
From a white box security review, you would need the System Auditor role, which allow to view all system data but cannot make any changes. Another option would be to get the Organization Auditor role, but it would be better to get the other one.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)