Rocco Sicilia

In molti ambiti dell’IT capita di costruirsi piccoli tools per automatizzare alcuni task o rendere più comodo alcune operazioni e solitamente questi tools vengono utilizzati localmente sulle proprie workstation/laptop. Più di recente mi è capitato di dover automatizzare operazioni con strumenti che avrei poi dovuto spostare su altri host e mi è venuto in mente che avrei potuto creare dei pacchetti facili da portare in giro. È stata l’occasione buona per rimettere mano a Docker e in questo post riporto qualche appunto molto operativo per chi è interessato a valutare l’utilizzo di container per propri piccoli progetti personali.

Ci sono anche dei risvolti sul fronte della sicurezza nell’utilizzo dei container ma ne parlo in un prossimo post.

Per prima cosa due note su come ho deciso di lavorare a livello di ambiente di sviluppo. Questo tema credo sia molto soggettivo e legato al proprio ambiente di lavoro: nel mio caso per le mie attività di lavoro / ricerca / studio uso il mio MacBook di servizio ed ho trovato comodo utilizzare Docker Desktop per la gestione ordinaria dei container. I restanti strumenti sono i soliti: con VS Code, Github ed il terminal si fa tutto.

Preparazione del progetto

Provo a fare uno step-by-step di come ho avviato la base del progetto che sto portando avanti in questo periodo, la versione containered del mio C2 di laboratorio, così ve la potete scaricare ed implementare comodamente dove vi pare.

Ovviamente come primo step ho creato il progetto sul mio Github, codename: portable_c2. Nella root dir di progetto ho preparato il Dockerfile con le istruzioni che mi serviranno per la creazione del container (ci ho messo un po’ per trovare la conf. più pulita che sono riuscito a definire):

Come si intuisce dal Dockerfile il container ospiterà un’applicazione molto semplice basata su python e la pubblicazione di alcuni elementi è affidata ad Apache. Va quindi predisposta la configurazione del web-server:

Molto semplicemente il container esporrà l’applicazione “c2” il cui codice sarà posizionato nella directory /app di cui, giusto per avviare il servizio, scriviamo del codice di test utile ad avere un output per fare qualche test.

In questo caso ci basta un file di base che verrà eseguito alla chiamata dell’app (app.py):

Per come funzionano le python app pubblicate via Apache è necessario avere a disposizione un file “ponte” che verrà chiamato direttamente da Apache e che vediamo anche nella conf. del web server con la direttiva WSGIScriptAlias per “app.wsgi”:

Come si intuisce il file in questione non fa altro che importare il codice di app.py. Ultima componente per quanto riguarda python è il requisito iniziale di flask e requests che andiamo a dichiarare nel file requirements.txt e che abbiamo già deciso di utilizzare nel nostro Dockerfile:

Per la configurazione del container possiamo definire dei parametri a livello di file di configurazione, nel mio caso il docker-compose.yml è così strutturato:

Per comodità ho deciso di usare un bind mount della directory /app. Non so se è la scelta migliora ma per ora procederò in questo modo. Per quanto riguarda la porta tcp da utilizzare per accedere all’app ho definito una tipica tcp\8080 mappata alla porta 80 di Apache web server all’interno del container. Questo significa che l’applicazione sarà disponibile sull’IP della macchina host via browser con una richiesta a http://a.b.c.d:8080.

Ingnore file

Ho sempre mal tollerato le repo incasinate quindi, se il progetto è strutturato, preferisco definire subito cosa mettere in ignore:

File .dockerignore:

File .gitignore:

VS code e container

Ora è tutto apparecchiato e possiamo procedere con la build del container che conterrà un’app di test.

Come si vede dallo screenshot il comando per eseguire la build è:

Ovviamente il comando ha senso se viene eseguito dalla directory in cui si trovano anche i file di configurazione che abbiamo preparato. Se tutto è stato configurato correttamente dovremmo poter accedere alla nostra applicazione di test con il browser.

C’è un trick, una funzionalità in realtà, molto interessante che mi permette di lavorare comodamente da VS Code per aggiornare la mia applicazione python: la chiamata volume nel file docker-compose.yml. Stiamo sostanzialmente chiadendo a Docker di tenere sincronizzato il contenuto della directory /app, ovverò l’area del file system locale che useremo per posizionare tutti i file dell’applicazione.

In questo modo a seguito di una modifica sarà sufficiente riavviare il servizio web senza eseguire una nuova build del container. Ovviamente se i change sono più profondi e riguardano la struttura stessa del container faremo semplicemente una nuova build.

Giusto per vedere cosa succede, nello screenshot ho eseguito una semplice modifica della print di test.

Eseguo il restart del servizio web con il comando:

Se non ci sono errori troveremo le modifiche applicate controllando l’output dell’applicazione:

Note di chiusura

Come ho accennato ci sono anche risvolti sul piano della sicurezza dei sistemi nell’uso dei container. Ho voluto condividervi i miei appunti anche per introdurre chi non conosce la tecnologia al contesto operativo per fare poi qualche ragionamento di legato all’ambito sec.

È un argomento molto DevOps che, pur non volendo metterlo tra i requisiti minimi per chi si occupa di sicurezza informativa, è sicuramente un tema importante su cui è molto utile avere qualche base.