HackTricks Cloud
HackTricks Training Twitter Linkedin Sponsor

Ansible Tower / AWX / Automation controller Security

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

Basic Information

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.

Differences

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.

Tech Stack

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

Logical Components

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

Job Execution Flow

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

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

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

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

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

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

AWX lab creation for testing

Following the docs it's possible to use docker-compose to run 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

Supported roles

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.

Expand this to get detailed description of available roles

  1. System Administrator:

    • This is the superuser role with permissions to access and modify any resource in the system.

    • They can manage all organizations, teams, projects, inventories, job templates, etc.

  2. System Auditor:

    • Users with this role can view all system data but cannot make any changes.

    • This role is designed for compliance and oversight.

  3. Organization Roles:

    • Admin: Full control over the organization's resources.

    • Auditor: View-only access to the organization's resources.

    • Member: Basic membership in an organization without any specific permissions.

    • Execute: Can run job templates within the organization.

    • Read: Can view the organization’s resources.

  4. Project Roles:

    • Admin: Can manage and modify the project.

    • Use: Can use the project in a job template.

    • Update: Can update project using SCM (source control).

  5. Inventory Roles:

    • Admin: Can manage and modify the inventory.

    • Ad Hoc: Can run ad hoc commands on the inventory.

    • Update: Can update the inventory source.

    • Use: Can use the inventory in a job template.

    • Read: View-only access.

  6. Job Template Roles:

    • Admin: Can manage and modify the job template.

    • Execute: Can run the job.

    • Read: View-only access.

  7. Credential Roles:

    • Admin: Can manage and modify the credentials.

    • Use: Can use the credentials in job templates or other relevant resources.

    • Read: View-only access.

  8. Team Roles:

    • Member: Part of the team but without any specific permissions.

    • Admin: Can manage the team's members and associated resources.

  9. Workflow Roles:

    • Admin: Can manage and modify the workflow.

    • Execute: Can run the workflow.

    • Read: View-only access.

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

PreviousOkta HardeningNextTODO

Last updated