La gestione sicura dei segreti è un aspetto importante della sicurezza dei container. Se stai inserendo password e chiavi API come variabili di ambiente, rischi l'esposizione involontaria delle informazioni. Le variabili della shell vengono spesso registrate, passate a processi figlio o divulgate a servizi di segnalazione degli errori a tua insaputa.
Iniettare valori come segreti dedicati mitiga questi rischi. Docker ha un supporto integrato per la gestione sicura dei segreti a cui puoi agganciarti con Docker Compose. L'accesso ai segreti è concesso in base al servizio.
Come funzionano i segreti?
La Docker CLI ha una serie di segreti comandi di gestione, ma funzionano solo con i cluster Swarm. Non puoi aggiungere segreti ai contenitori autonomi utilizzando la sola CLI di Docker.
Docker Compose ha aggiunto “falso” segreti per portare queste funzionalità ai carichi di lavoro senza un cluster. L’implementazione di Compose funziona in modo simile alle funzionalità di Docker Swarm e funziona con qualsiasi file Compose.
I segreti vengono creati come normali file di testo che vengono montati nei contenitori. La tua applicazione accede al valore del segreto leggendo il contenuto del file. Questo modello consente ai valori di rimanere inerti finché non vengono utilizzati esplicitamente all'interno del contenitore, a differenza delle variabili di ambiente permanentemente visibili.
Definizione dei segreti nei file di composizione
L'inserimento di un segreto in un contenitore è un processo in due fasi. Per prima cosa devi definire il segreto, usando il campo dei segreti di primo livello nel tuo file Compose. Quindi aggiorni le definizioni del servizio per fare riferimento ai segreti richiesti.
Pubblicità
Ecco un esempio che utilizza i segreti per fornire in modo sicuro una password a un servizio:
versione: “3” servizi: app: immagine: esempio-app:latest segreti: – db_password segreti: db_password: file: ./db_password.txt
Il valore del segreto verrà letto dalla tua directory di lavoro’ ;s file db_password.txt quando esegui docker-compose up. Compose monterà il file in /run/secrets/db_password all'interno del contenitore. La tua app può accedere alla password del database leggendo il contenuto del file segreto.
Uso dei segreti Docker esistenti
Oltre ai segreti basati su file, Compose ti consente anche di fare riferimento ai segreti Docker Swarm esistenti. Se utilizzi questo meccanismo, devi creare i segreti in Docker prima di eseguire docker-compose up. Lo spazio dei comandi dei segreti docker funzionerà solo quando l'endpoint Docker attivo è un nodo gestore Swarm.
Crea il segreto utilizzando la CLI Docker:
# prendi valore dall'input standard echo P@55w0rd | docker secret crea db_password – OPPURE # prende valore da un file docker secret create db_password ./db_password.txt
Ora aggiorna il tuo file Docker Compose per fare riferimento al segreto:
versione: “3” services: app: image: example-app:latest secrets: – db_password segreti: db_password: external: true
Impostazione del segreto’ Il campo esterno di ;s indica a Compose di ricavare il suo valore dai tuoi segreti Docker esistenti. Lo stack fallirà con un errore se si tenta di avviarlo prima che il segreto esista.
Sintassi del segreto esteso
Compose supporta una sintassi dei segreti più lunga se è necessario un controllo più granulare sul processo di iniezione. Il passaggio a questa sintassi consente di personalizzare i permessi dei file e modificare il nome montato del segreto.
Sono disponibili cinque campi facoltativi:
- origine – Il nome del segreto a cui fare riferimento – questo deve essere uno dei valori definiti nella sezione dei segreti del file Compose.
- target – Nome file da utilizzare quando il segreto viene montato nel contenitore.
- uid– UID da impostare sul file segreto montato. Il valore predefinito è 0.
- gid – GID da impostare sul file segreto montato. Il valore predefinito è 0.
- modalità – Permessi del filesystem da applicare al file segreto montato, espressi in notazione ottale. Il valore predefinito è 0444. Attenzione che i file segreti non sono mai scrivibili poiché sono sempre montati nel filesystem temporaneo di un contenitore.
Annuncio
Ecco un esempio modificato che rinomina il file segreto montato e ne cambia i permessi:
versione: “3” services: app: image: example-app:latest secrets: – source: db_password target: database_password_secret mode: 0440 segreti: db_password: external: true
La semplice sintassi è generalmente sufficiente per la maggior parte delle distribuzioni. Se hai requisiti più specifici, la versione estesa dovrebbe darti il controllo di cui hai bisogno. I singoli riferimenti segreti possono combinare e abbinare le due sintassi all'interno dello stesso file Compose.
Segreti e autore delle immagini
Molte popolari immagini Docker della community ora supportano i segreti invece delle variabili di ambiente. In qualità di autore di immagini, offrire segreti è un approccio di best practice per proteggere i tuoi utenti’ dati.
È possibile supportare entrambi i meccanismi consentendo di impostare le variabili di ambiente su un percorso di file. Se la tua immagine necessita di una connessione al database, consenti agli utenti di impostare la variabile di ambiente DB_PASSWORD su P@55w0rd o /run/secrets/db_password. Il tuo contenitore dovrebbe verificare se il valore della variabile fa riferimento a un file valido; se lo fa, scartalo e leggi il valore finale dal file.
Questo modello offre agli utenti la flessibilità di scegliere il meccanismo più appropriato per la loro distribuzione. Ricorda che non tutti gli utenti saranno in grado di adottare i segreti – se Swarm e Compose non sono entrambi disponibili, non avranno modo di fornire i loro valori.
Conclusione
L'utilizzo di segreti invece delle normali variabili di ambiente riduce i rischi di divulgazione involontaria di informazioni. Immagina lo scenario peggiore in cui un container invia le sue variabili di ambiente a un servizio di registrazione di terze parti compromesso. Gli aggressori ora hanno la password del database e le chiavi API.
Pubblicità
Limitando i dati segreti all'accesso al filesystem, i valori non possono essere letti inavvertitamente poiché non sono una caratteristica perpetua del tuo ambiente. Ricorda però che i file segreti comportano i loro rischi. Potresti essere tentato di inserirli nel controllo del codice sorgente, il che significherebbe che chiunque abbia accesso al tuo repository potrebbe leggere i loro valori.
I segreti dovrebbero essere “segreti” per tutto il ciclo di vita del contenitore. Per le distribuzioni di produzione, di solito è meglio automatizzare le build con un sistema CI. Imposta i tuoi segreti nelle impostazioni della pipeline del tuo provider CI, quindi usa lo script di build per scriverli in file a cui Compose può accedere. Ciò garantisce che solo tu abbia accesso ai valori effettivi, tramite l'interfaccia del tuo strumento CI.