Sicurezza di Ansible Tower / AWX / Automation Controller

Reading time: 11 minutes

Informazioni di base

Ansible Tower o la sua versione open source 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, 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 è possibile utilizzare docker-compose per eseguire 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

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.

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

# 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:

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:

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
• BloodHound OSS