Ho trovato password in chiaro nel mio docker-compose (e non erano nel .env)

Non stavo facendo un audit di sicurezza. Stavo semplicemente decidendo quali file indicizzare per l’assistente RAG di cui ho parlato nell’articolo precedente, e per farlo dovevo rileggere per intero il docker-compose.yml dei quindici servizi che tengo in produzione. È lì che li ho trovati: due valori sensibili scritti in chiaro, esposti nel file di configurazione, mentre le variabili corrispondenti esistevano già (inutilizzate) in un file .env dedicato proprio a evitare questo.

La convinzione sbagliata: “ho un .env, sono a posto”

Da tempo tengo i segreti dell’homelab in un file .env separato dal resto della configurazione, prassi che consideravo corretta e sufficiente. E per la maggior parte dei servizi lo è davvero: le variabili sono lì, richiamate correttamente nei file compose con la sintassi giusta.

Quello che mancava non era la disciplina di partenza. Era la verifica che ogni singolo servizio rispettasse davvero quella disciplina, e non solo la maggioranza di essi.

Cosa ho trovato

Un servizio di backup aveva una chiave di cifratura e una password di accesso all’interfaccia web scritte direttamente nel docker-compose.yml, in chiaro. Non erano un residuo dimenticato da una versione precedente: erano i valori attivi, quelli che il servizio stava davvero usando in quel momento.

La parte che mi ha sorpreso di più: nel .env esistevano già due variabili con nomi coerenti, pronte per contenere esattamente questi due valori. Non erano mai state collegate al servizio. Il file giusto c’era. Il collegamento no.

Come è potuto succedere

Non ho una certezza, solo un’ipotesi ragionevole basata su come è cresciuto l’homelab nel tempo: probabile che il .env sia stato aggiornato o esteso in un momento diverso da quando quel servizio specifico è stato configurato, e il collegamento tra i due si sia perso nel mezzo. Non è successo per fretta evidente o negligenza riconoscibile: è il tipo di scollamento silenzioso che capita quando un sistema si costruisce a pezzi nel tempo, non tutto insieme in una sessione.

Come li ho trovati

Niente di sofisticato: una ricerca testuale mirata, dentro i file compose, su un piccolo set di parole chiave tipiche di un segreto: password, key, secret, token, e le loro varianti più comuni. Non serve un tool dedicato per questo primo passaggio, serve solo pensare a farlo.

Il punto degno di nota è perché l’ho fatto quel giorno: stavo lavorando su tutt’altro. È un promemoria a rileggere ogni tanto i propri file di configurazione anche senza un motivo specifico per farlo: le cose pericolose in un homelab spesso non si trovano cercandole apposta.

Come li ho sistemati

Quattro passaggi, in quest’ordine:

1. Backup del file originale prima di toccare niente.
2. Sostituzione dei valori in chiaro con riferimenti alle variabili già esistenti nel .env, con la sintassi standard di interpolazione di Docker Compose.
3. Verifica con docker compose config che le variabili si risolvessero correttamente prima di riavviare qualsiasi cosa: questo comando mostra la configurazione finale, con le variabili già sostituite, senza avviare nulla.
4. Riavvio del servizio e controllo dei log per assicurarmi che partisse senza errori di configurazione, con le stesse credenziali di prima ma prese dalla fonte giusta.

Nessun downtime imprevisto, nessuna credenziale cambiata, solo spostata da un posto sbagliato a quello giusto, dove già avrebbe dovuto essere.

Perché può succedere anche a te

Non serve essere disattenti. Basta aggiungere un servizio “al volo” per provarlo velocemente, scrivere un valore a mano per non perdere tempo a collegarlo al .env in quel momento, e poi non tornarci più, perché il servizio funziona, e quello che funziona tende a restare invisibile. Il rischio non nasce dall’ignorare la buona pratica: nasce dall’applicarla in modo incompleto, un servizio alla volta, senza mai fare un controllo d’insieme.

Checklist rapida per il tuo homelab

• Cerca le parole chiave tipiche di un segreto (password, key, secret, token, pwd) in tutti i tuoi file docker-compose.yml
• Per ogni corrispondenza, verifica se esiste già una variabile equivalente nel tuo .env
• Se esiste, collegala e verifica con docker compose config prima di riavviare
• Se non esiste, creala prima di procedere, non lasciare il valore in chiaro “per ora”
• Ripeti il controllo ogni volta che aggiungi un nuovo servizio, non solo una volta per tutte

Domande frequenti

Un file .env è sufficiente per proteggere i segreti di Docker Compose?

È un buon punto di partenza, ma non basta da solo: serve anche verificare che ogni servizio richiami davvero le variabili dal .env invece di avere valori scritti direttamente nel file compose. Avere il file giusto non garantisce che venga usato ovunque dovrebbe.

Come si cercano password o chiavi scritte in chiaro nei file di configurazione?

Una ricerca testuale sui file docker-compose.yml per parole chiave come password, key, secret o token è un primo controllo semplice ed efficace, da ripetere periodicamente e non solo una tantum.

Docker Compose supporta le variabili d’ambiente da file esterno?

Sì, tramite un file .env nella stessa cartella del docker-compose.yml, richiamato nel file compose con la sintassi ${NOME_VARIABILE}. La presenza del file da sola non garantisce che tutti i servizi lo usino correttamente: va verificato.

Conclusione

Non è la storia di un errore grave lasciato lì per pigrizia. È la storia di una buona pratica applicata bene ovunque tranne in un punto, trovata per caso mentre facevo tutt’altro. Il messaggio non è “usa un .env“: quello lo sapevo già. È che avere la pratica giusta non basta se non la verifichi anche dove pensi di averla già applicata.

Questo articolo fa parte di IA locale su hardware di recupero, la serie in cui provo a far girare modelli in locale su un PC del 2013 misurando tutto: cosa gira davvero, quanto costa tenerlo acceso, a cosa serve. Nell’indice ci sono tutti gli articoli in ordine.