Sicurezza di Ansible Tower / AWX / Automation Controller

Reading time: 9 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. Ciò 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 eseguire i 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 ai lavori di essere pianificati per essere eseguiti in momenti 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 del Lavoro

1. Interazione dell'Utente: Un utente può interagire con AWX/Tower sia tramite l'Interfaccia Web che tramite 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 ai risultati del lavoro, 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:

• Inventari possono essere recuperati dinamicamente da sistemi esterni, consentendo ad AWX/Tower di estrarre host da fonti come AWS, Azure, VMware e altro.
• Progetti (playbook) possono essere recuperati da sistemi di controllo versione, garantendo l'uso di playbook aggiornati durante l'esecuzione del lavoro.
• 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 più privilegiato è chiamato System Administrator. Chiunque abbia questo ruolo può modificare qualsiasi cosa.

Da una revisione di white box security, 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.