Docker Compose secrets: file montati e password nei log

Per togliere password e token dalle variabili d’ambiente dei container in Docker Compose, definisci i secret in compose.yaml, assegnali solo ai servizi che li usano e fai leggere le credenziali dai file in /run/secrets. La guida Docker ai secret in Compose descrive il montaggio per servizio. Il valore non compare più nella variabile d’ambiente del container: si riduce così il rischio che finisca nei log quando l’ambiente viene stampato.

Il file montato non impedisce però all’applicazione di registrare una password dopo averla letta. La guida OWASP alla gestione dei secret segnala che le variabili d’ambiente possono comparire nei log o nei dump di sistema e sconsiglia di incorporare credenziali nelle immagini con ENV o ARG. La migrazione elimina un canale di esposizione; restano da proteggere l’applicazione e il file di origine sull’host.

Individua le credenziali e chi le usa

Esamina environment ed env_file di ogni servizio. Host, porta e nome del database possono restare normali parametri di configurazione; password, token e chiavi sono i valori da spostare. Un riferimento come ${DB_PASSWORD} evita di scrivere la password direttamente nel compose.yaml, ma se lo assegni a environment il valore diventa comunque una variabile del container.

Per ciascuna credenziale annota il servizio che deve leggerla e il nome della variabile attuale. Tieni distinti i privilegi: la password usata dall’applicazione per collegarsi al database può servire a due servizi, mentre quella dell’amministratore del database deve restare nel solo servizio database. Questa mappa stabilisce quali secret dichiarare e previene concessioni superflue.

Prima: la password passa dall’ambiente

Considera un esempio ipotetico con un servizio db basato su MySQL e un servizio web basato su WordPress. Nella configurazione iniziale, db riceve MYSQL_PASSWORD: ${DB_PASSWORD} e MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}; web riceve WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}. I valori potrebbero provenire da un file .env, ma entrano comunque nell’ambiente dei rispettivi container.

La stessa password applicativa viene assegnata a db e web; quella amministrativa serve soltanto a db. Prima di modificare i nomi, controlla anche script di avvio, processi ausiliari e configurazioni dell’applicazione che leggono le vecchie variabili. La migrazione deve cambiare il modo in cui la credenziale viene consegnata, senza lasciare un componente che continui a cercarla nell’ambiente.

Dopo: un file per valore, accesso per servizio

Crea sul sistema host ./secrets/db_password.txt e ./secrets/db_root_password.txt con i rispettivi valori. Nel compose.yaml, la sezione secrets di primo livello associa db_password al primo file tramite file: ./secrets/db_password.txt e db_root_password al secondo tramite file: ./secrets/db_root_password.txt. I file contengono il valore della credenziale, non un’assegnazione del tipo DB_PASSWORD=valore.

In db, rimuovi MYSQL_PASSWORD e MYSQL_ROOT_PASSWORD da environment. Imposta MYSQL_PASSWORD_FILE: /run/secrets/db_password e MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password; nella lista secrets del servizio inserisci db_password e db_root_password.
In web, rimuovi WORDPRESS_DB_PASSWORD da environment. Imposta WORDPRESS_DB_PASSWORD_FILE: /run/secrets/db_password e inserisci soltanto db_password nella lista secrets del servizio.
Lascia in environment i parametri non sensibili, come MYSQL_DATABASE, MYSQL_USER, WORDPRESS_DB_HOST e WORDPRESS_DB_USER. Escludi i file con i valori reali dal repository e dal contesto di build prima di condividere il progetto.

La dichiarazione di primo livello indica dove Compose trova il valore; la lista secrets del singolo servizio concede l’accesso. Nel container db compaiono entrambi i file sotto /run/secrets; nel container web compare solo db_password. Un secret definito in cima al compose.yaml non viene montato automaticamente in tutti i servizi.

La convenzione _FILE dipende dall’immagine

MYSQL_PASSWORD_FILE e WORDPRESS_DB_PASSWORD_FILE contengono il percorso del file, non la password. Le immagini dell’esempio leggono quel percorso, ma il suffisso _FILE non è una funzione generale di Compose. Per un altro servizio, verifica che l’immagine supporti proprio la variabile prevista prima di sostituire il valore in environment.

Se un’applicazione accetta solo API_TOKEN come valore, aggiungere API_TOKEN_FILE potrebbe non avere alcun effetto. In quel caso deve leggere direttamente, per esempio, /run/secrets/api_token, oppure usare un’opzione documentata che accetti il percorso di un file. Uno script che legge il secret e poi esporta il contenuto come variabile d’ambiente riapre il canale di esposizione appena eliminato.

Il montaggio del secret riguarda i container Linux supportati da Compose. In questa configurazione locale il valore proviene da un file dell’host: il nome _FILE indica soltanto come l’applicazione lo consuma, non offre di per sé cifratura, rotazione o controllo su chi possa leggere il file sorgente.

Controlla log, repository e file sull’host

Dopo la modifica, verifica che db trovi entrambe le credenziali e web soltanto quella applicativa, poi controlla l’avvio e gli errori di autenticazione. Esamina i log e gli script di ingresso: un’applicazione può ancora stampare il contenuto letto dal file, passarlo come argomento di comando o includerlo in una configurazione registrata per il debug. Se una vecchia password è già presente nei log o nella cronologia Git, trattala come esposta e sostituiscila.

Il modello di fiducia di Docker Compose avverte che i riferimenti file: possono leggere file accessibili a chi esegue Compose, anche tramite collegamenti simbolici, e che il contenuto può emergere durante la risoluzione della configurazione, compreso l’output di docker compose config. Limita quindi i permessi dei file sull’host, esamina le modifiche al compose.yaml e controlla quell’output prima di conservarlo o pubblicarlo.

Prima di condividere o distribuire la configurazione, usa questa checklist:

I file con i valori reali sono esclusi dal repository e dal contesto di build; eventuali file di esempio contengono soltanto segnaposto. Se un file era già tracciato, aggiungerlo a .gitignore non ne elimina le copie precedenti.
Ogni servizio dichiara soltanto i secret necessari e ogni variabile _FILE usata è supportata dall’immagine o dall’applicazione.
Log, pipeline, script di avvio e comandi di configurazione non diffondono il contenuto dei file né lo copiano nuovamente nell’ambiente.
La conservazione del valore di origine, la sua rotazione e la revoca hanno procedure proprie, soprattutto quando le credenziali devono raggiungere più macchine o ambienti.