Ansible Tower / AWX / Automation controller Security
Informazioni di base
Ansible Tower o la sua versione open source AWX è anche conosciuto 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 lo rendono semplice da integrare con gli strumenti e i flussi di lavoro attuali.
Automation Controller è una versione più recente di Ansible Tower con maggiori funzionalità.
Differenze
Secondo questo, le principali differenze tra Ansible Tower e AWX sono il supporto ricevuto e il fatto che Ansible Tower ha funzionalità aggiuntive come il controllo degli accessi basato sui ruoli, il supporto per API personalizzate e flussi di lavoro definiti dall'utente.
Stack Tecnologico
Interfaccia Web: Questa è l'interfaccia grafica dove 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.
API REST: 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 script azioni che eseguiresti tipicamente 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 raccolta di host (o nodi) contro i quali possono essere eseguiti lavori (playbook di 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 raccolta di playbook di 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 è basato su Ansible e è responsabile di eseguire i playbook. I lavori vengono inviati al motore di task, che quindi esegue i playbook di Ansible contro l'inventario designato utilizzando le credenziali specificate.
Pianificatori e Callback: Queste sono funzionalità avanzate in AWX/Tower che consentono di pianificare lavori 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 notifica come email, messaggi Slack, webhook, ecc.
Playbook di Ansible: I playbook di Ansible sono strumenti di configurazione, distribuzione e orchestratura. Descrivono lo stato desiderato dei sistemi in modo automatizzato e ripetibile. Scritti in YAML, i playbook utilizzano il linguaggio di automazione dichiarativo di Ansible per descrivere configurazioni, compiti e passaggi che devono essere eseguiti.
Flusso di Esecuzione del Lavoro
Interazione dell'Utente: Un utente può interagire con AWX/Tower tramite l'Interfaccia Web o l'API REST. Questi forniscono accesso front-end a tutte le funzionalità offerte da AWX/Tower.
Inizializzazione 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.
All'avvio del lavoro, viene inviata una richiesta al backend di AWX/Tower per mettere in coda il lavoro per l'esecuzione.
Accodamento 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.
Esecuzione del Lavoro:
Il Motore di Task prende il lavoro in coda. Recupera le informazioni necessarie dal Database sul playbook associato al lavoro, sull'inventario e sulle credenziali.
Utilizzando il playbook di Ansible recuperato dal Progetto associato, il Motore di Task esegue il playbook contro i nodi specificati dell'Inventario utilizzando le Credenziali fornite.
Mentre il playbook viene eseguito, il suo output di esecuzione (log, fatti, ecc.) viene catturato e memorizzato nel Database.
Risultati del Lavoro:
Una volta completata l'esecuzione del playbook, 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 dello stato del lavoro. Le notifiche potrebbero essere email, messaggi Slack, webhook, ecc.
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 dai 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, consentendo ad AWX/Tower di reagire a trigger esterni o eseguire lavori in momenti prestabiliti.
Creazione di un laboratorio AWX per test
Seguendo la documentazione è possibile utilizzare docker-compose per eseguire AWX:
RBAC
Ruoli supportati
Il ruolo più privilegiato è chiamato Amministratore di Sistema. Chiunque abbia questo ruolo può modificare qualsiasi cosa.
Da una revisione di sicurezza white box, avresti bisogno del ruolo di Auditor di Sistema, che consente di visualizzare tutti i dati di sistema ma non può apportare modifiche. Un'altra opzione sarebbe ottenere il ruolo di Auditor dell'Organizzazione, ma sarebbe meglio ottenere l'altro.
Last updated