# Sicurezza di Ansible Tower / AWX / Automation Controller

{{#include ../banners/hacktricks-training.md}}

## Informazioni di base

**Ansible Tower** o la sua versione open source [**AWX**](https://github.com/ansible/awx) è conosciuta anche come **interfaccia utente di Ansible, dashboard e REST API**. Con **controllo degli accessi basato sui ruoli**, pianificazione dei lavori e gestione grafica dell'inventario, puoi gestire la tua infrastruttura Ansible da un'interfaccia moderna. L'API REST di Tower e l'interfaccia a riga di comando rendono semplice integrarla negli strumenti e nei flussi di lavoro attuali.

**Automation Controller è una versione** più recente di Ansible Tower con maggiori capacità.

### Differenze

Secondo [**questo**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), le principali differenze tra Ansible Tower e AWX sono il supporto ricevuto e Ansible Tower ha funzionalità aggiuntive come il controllo degli accessi basato sui ruoli, supporto per API personalizzate e flussi di lavoro definiti dall'utente.

### Stack Tecnologico

- **Interfaccia Web**: Questa è l'interfaccia grafica in cui gli utenti possono gestire inventari, credenziali, modelli e lavori. È progettata per essere intuitiva e fornisce visualizzazioni per aiutare a comprendere lo stato e i risultati dei tuoi lavori di automazione.
- **REST API**: Tutto ciò che puoi fare nell'interfaccia web, puoi farlo anche tramite l'API REST. Questo significa che puoi integrare AWX/Tower con altri sistemi o scriptare azioni che normalmente esegui nell'interfaccia.
- **Database**: AWX/Tower utilizza un database (tipicamente PostgreSQL) per memorizzare la sua configurazione, i risultati dei lavori e altri dati operativi necessari.
- **RabbitMQ**: Questo è il sistema di messaggistica utilizzato da AWX/Tower per comunicare tra i diversi componenti, specialmente tra il servizio web e i task runner.
- **Redis**: Redis funge da cache e backend per la coda dei task.

### Componenti Logici

- **Inventari**: Un inventario è una **collezione di host (o nodi)** contro cui possono essere **eseguiti** i **lavori** (playbook Ansible). AWX/Tower ti consente di definire e raggruppare i tuoi inventari e supporta anche inventari dinamici che possono **recuperare elenchi di host da altri sistemi** come AWS, Azure, ecc.
- **Progetti**: Un progetto è essenzialmente una **collezione di playbook Ansible** provenienti da un **sistema di controllo versione** (come Git) per estrarre i playbook più recenti quando necessario.
- **Modelli**: I modelli di lavoro definiscono **come verrà eseguito un particolare playbook**, specificando l'**inventario**, le **credenziali** e altri **parametri** per il lavoro.
- **Credenziali**: AWX/Tower fornisce un modo sicuro per **gestire e memorizzare segreti, come chiavi SSH, password e token API**. Queste credenziali possono essere associate ai modelli di lavoro in modo che i playbook abbiano l'accesso necessario quando vengono eseguiti.
- **Motore di Task**: Qui avviene la magia. Il motore di task è costruito su Ansible ed è responsabile per **l'esecuzione dei playbook**. I lavori vengono inviati al motore di task, che poi esegue i playbook Ansible contro l'inventario designato utilizzando le credenziali specificate.
- **Pianificatori e Callback**: Queste sono funzionalità avanzate in AWX/Tower che consentono di **pianificare i lavori** per essere eseguiti in orari specifici o attivati da eventi esterni.
- **Notifiche**: AWX/Tower può inviare notifiche in base al successo o al fallimento dei lavori. Supporta vari mezzi di notifiche come email, messaggi Slack, webhook, ecc.
- **Playbook Ansible**: I playbook Ansible sono strumenti di configurazione, distribuzione e orchestrazione. Descrivono lo stato desiderato dei sistemi in modo automatizzato e ripetibile. Scritti in YAML, i playbook utilizzano il linguaggio di automazione dichiarativa di Ansible per descrivere configurazioni, attività e passaggi che devono essere eseguiti.

### Flusso di Esecuzione dei Lavori

1. **Interazione dell'Utente**: Un utente può interagire con AWX/Tower sia tramite l'**Interfaccia Web** che l'**API REST**. Queste forniscono accesso front-end a tutte le funzionalità offerte da AWX/Tower.
2. **Inizio del Lavoro**:
- L'utente, tramite l'Interfaccia Web o l'API, avvia un lavoro basato su un **Modello di Lavoro**.
- Il Modello di Lavoro include riferimenti all'**Inventario**, al **Progetto** (contenente il playbook) e alle **Credenziali**.
- Al momento dell'inizio del lavoro, viene inviata una richiesta al backend di AWX/Tower per mettere in coda il lavoro per l'esecuzione.
3. **Coda del Lavoro**:
- **RabbitMQ** gestisce la messaggistica tra il componente web e i task runner. Una volta avviato un lavoro, un messaggio viene inviato al motore di task utilizzando RabbitMQ.
- **Redis** funge da backend per la coda dei task, gestendo i lavori in coda in attesa di esecuzione.
4. **Esecuzione del Lavoro**:
- Il **Motore di Task** preleva il lavoro in coda. Recupera le informazioni necessarie dal **Database** riguardo al playbook associato al lavoro, all'inventario e alle credenziali.
- Utilizzando il playbook Ansible recuperato dal **Progetto** associato, il Motore di Task esegue il playbook contro i nodi dell'**Inventario** specificato utilizzando le **Credenziali** fornite.
- Mentre il playbook viene eseguito, il suo output di esecuzione (log, fatti, ecc.) viene catturato e memorizzato nel **Database**.
5. **Risultati del Lavoro**:
- Una volta che il playbook ha terminato l'esecuzione, i risultati (successo, fallimento, log) vengono salvati nel **Database**.
- Gli utenti possono quindi visualizzare i risultati tramite l'Interfaccia Web o interrogarli tramite l'API REST.
- In base agli esiti dei lavori, le **Notifiche** possono essere inviate per informare gli utenti o i sistemi esterni sullo stato del lavoro. Le notifiche possono essere email, messaggi Slack, webhook, ecc.
6. **Integrazione con Sistemi Esterni**:
- Gli **Inventari** possono essere recuperati dinamicamente da sistemi esterni, consentendo ad AWX/Tower di estrarre host da fonti come AWS, Azure, VMware e altro.
- I **Progetti** (playbook) possono essere recuperati da sistemi di controllo versione, garantendo l'uso di playbook aggiornati durante l'esecuzione del lavoro.
- I **Pianificatori e Callback** possono essere utilizzati per integrarsi con altri sistemi o strumenti, facendo sì che AWX/Tower reagisca a trigger esterni o esegua lavori a orari prestabiliti.

### Creazione di un laboratorio AWX per test

[**Seguendo la documentazione**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) è possibile utilizzare docker-compose per eseguire AWX:
```bash
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

### Ruoli supportati

Il ruolo con il maggior privilegio è chiamato **System Administrator**. Chiunque abbia questo ruolo può **modificare qualsiasi cosa**.

Da una revisione della **sicurezza white box**, avresti bisogno del **System Auditor role**, che consente di **visualizzare tutti i dati di sistema** ma non può apportare modifiche. Un'altra opzione sarebbe ottenere il **Organization Auditor role**, ma sarebbe meglio ottenere l'altro.

<details>

<summary>Espandi per ottenere una descrizione dettagliata dei ruoli disponibili</summary>

1. **System Administrator**:
- Questo è il ruolo superutente con permessi per accedere e modificare qualsiasi risorsa nel sistema.
- Può gestire tutte le organizzazioni, i team, i progetti, gli inventari, i modelli di lavoro, ecc.
2. **System Auditor**:
- Gli utenti con questo ruolo possono visualizzare tutti i dati di sistema ma non possono apportare modifiche.
- Questo ruolo è progettato per la conformità e la supervisione.
3. **Ruoli dell'organizzazione**:
- **Admin**: Controllo completo sulle risorse dell'organizzazione.
- **Auditor**: Accesso in sola lettura alle risorse dell'organizzazione.
- **Member**: Membro base in un'organizzazione senza permessi specifici.
- **Execute**: Può eseguire modelli di lavoro all'interno dell'organizzazione.
- **Read**: Può visualizzare le risorse dell'organizzazione.
4. **Ruoli del progetto**:
- **Admin**: Può gestire e modificare il progetto.
- **Use**: Può utilizzare il progetto in un modello di lavoro.
- **Update**: Può aggiornare il progetto utilizzando SCM (controllo sorgente).
5. **Ruoli dell'inventario**:
- **Admin**: Può gestire e modificare l'inventario.
- **Ad Hoc**: Può eseguire comandi ad hoc sull'inventario.
- **Update**: Può aggiornare la fonte dell'inventario.
- **Use**: Può utilizzare l'inventario in un modello di lavoro.
- **Read**: Accesso in sola lettura.
6. **Ruoli del modello di lavoro**:
- **Admin**: Può gestire e modificare il modello di lavoro.
- **Execute**: Può eseguire il lavoro.
- **Read**: Accesso in sola lettura.
7. **Ruoli delle credenziali**:
- **Admin**: Può gestire e modificare le credenziali.
- **Use**: Può utilizzare le credenziali in modelli di lavoro o altre risorse pertinenti.
- **Read**: Accesso in sola lettura.
8. **Ruoli del team**:
- **Member**: Parte del team ma senza permessi specifici.
- **Admin**: Può gestire i membri del team e le risorse associate.
9. **Ruoli del workflow**:
- **Admin**: Può gestire e modificare il workflow.
- **Execute**: Può eseguire il workflow.
- **Read**: Accesso in sola lettura.

</details>

## Enumerazione e Mappatura del Percorso di Attacco con AnsibleHound

`AnsibleHound` è un collezionista BloodHound *OpenGraph* open-source scritto in Go che trasforma un token API di Ansible Tower/AWX/Automation Controller **in sola lettura** in un grafico di permessi completo pronto per essere analizzato all'interno di BloodHound (o BloodHound Enterprise).

### Perché è utile?
1. L'API REST di Tower/AWX è estremamente ricca ed espone **ogni oggetto e relazione RBAC** di cui la tua istanza è a conoscenza.
2. Anche con il token di privilegio più basso (**Read**) è possibile enumerare ricorsivamente tutte le risorse accessibili (organizzazioni, inventari, host, credenziali, progetti, modelli di lavoro, utenti, team…).
3. Quando i dati grezzi vengono convertiti nello schema di BloodHound, ottieni le stesse capacità di visualizzazione del *percorso di attacco* che sono così popolari nelle valutazioni di Active Directory – ma ora dirette verso il tuo patrimonio CI/CD.

I team di sicurezza (e gli attaccanti!) possono quindi:
* Comprendere rapidamente **chi può diventare admin di cosa**.
* Identificare **credenziali o host che sono raggiungibili** da un account non privilegiato.
* Collegare più bordi “Read ➜ Use ➜ Execute ➜ Admin” per ottenere il pieno controllo sull'istanza di Tower o sull'infrastruttura sottostante.

### Requisiti
* Ansible Tower / AWX / Automation Controller raggiungibile tramite HTTPS.
* Un token API utente limitato a **Read** solo (creato da *User Details → Tokens → Create Token → scope = Read*).
* Go ≥ 1.20 per compilare il collezionista (o utilizzare i binari precompilati).

### Costruzione e Esecuzione
```bash
# 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"
```
Internamente, AnsibleHound esegue richieste `GET` *paginati* contro (almeno) i seguenti endpoint e segue automaticamente i link `related` restituiti in ogni oggetto 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/
```
Tutte le pagine raccolte vengono unite in un unico file JSON su disco (predefinito: `ansiblehound-output.json`).

### Trasformazione BloodHound
I dati grezzi di Tower vengono quindi **trasformati in BloodHound OpenGraph** utilizzando nodi personalizzati con il prefisso `AT` (Ansible Tower):
* `ATOrganization`, `ATInventory`, `ATHost`, `ATJobTemplate`, `ATProject`, `ATCredential`, `ATUser`, `ATTeam`

E edge che modellano relazioni / privilegi:
* `ATContains`, `ATUses`, `ATExecute`, `ATRead`, `ATAdmin`

Il risultato può essere importato direttamente in BloodHound:
```bash
neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json
```
Facoltativamente, puoi caricare **icone personalizzate** in modo che i nuovi tipi di nodi siano visivamente distinti:
```bash
python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"
```
### Considerazioni Difensive e Offensive
* Un token *Read* è normalmente considerato innocuo ma rivela comunque la **topologia completa e ogni metadato delle credenziali**. Trattalo come sensibile!
* Applica il **principio del minimo privilegio** e ruota / revoca i token non utilizzati.
* Monitora l'API per eccessiva enumerazione (richieste `GET` sequenziali multiple, alta attività di paginazione).
* Dal punto di vista di un attaccante, questa è una tecnica perfetta di *punto d'appoggio iniziale → escalation dei privilegi* all'interno della pipeline CI/CD.

## Riferimenti
* [AnsibleHound – BloodHound Collector per Ansible Tower/AWX](https://github.com/TheSleekBoyCompany/AnsibleHound)
* [BloodHound OSS](https://github.com/BloodHoundAD/BloodHound)

{{#include ../banners/hacktricks-training.md}}
