Passando in modo sicuro le chiavi segrete ai contenitori docker

Question

Passando in modo sicuro le chiavi segrete ai contenitori docker

#1 da (9 voti)
#2 da (6 voti)

33

Voglio passare un valore segreto richiesto da un'app che viene eseguita in un contenitore Docker. Questo particolare contenitore è di breve durata: si avvia, esegue un comando e quindi termina.

Metodo 1: passare il valore come variabile di ambiente tramite la riga di comando all'avvio del contenitore (Docker supporta questo come argomento della riga di comando per avviare un contenitore). Mi sembra che questo non funzioni poiché il comando verrà visualizzato negli elenchi del processo (con la chiave e tutti) sul computer host che ha avviato il contenitore finestra mobile.

Metodo 2: passare il valore come variabile env tramite un file variabile env. Questo risolve il problema dell'elenco dei processi, ma l'esecuzione di docker info sul contenitore in esecuzione dall'host mostra un elenco di tutte le variabili di ambiente impostate per quel contenitore. Questo mi fa pensare che Docker stia memorizzandoli da qualche parte su disco sull'host che non è sicuro (dal momento che aggiungere una nuova variabile di ambiente nel contenitore in esecuzione non aggiorna questo elenco, non deve essere letto direttamente in tempo reale).

In generale, mi sembra che le variabili di ambiente non siano adeguate per archiviare in modo sicuro i dati segreti (anche se solo temporaneamente), ma non ho abbastanza conoscenza per eseguire il backup di questo pensiero.

Che cos'è un metodo sicuro per trasferire dati segreti in un contenitore?

docker key-management

posta Anthony Kraft 16.10.2014 - 04:11

fonte

2 risposte

6

Gli utenti di Docker hanno recentemente introdotto la loro soluzione nativa per questo: link

Il modello di utilizzo è:

$ echo "This is a secret" | docker secret create my_secret_data -
$ docker service  create --name="redis" --secret="my_secret_data" redis:alpine

Il segreto non crittografato viene quindi montato nel contenitore in un filesystem in memoria a /run/secrets/<secret_name> .

Anche se è accessibile solo in swarm

Puoi trovare la documentazione completa qui: link

risposta data 27.04.2017 - 13:21

fonte

Leggi altre domande sui tag docker key-management

Una sessione SSH su un sito errato è un'esposizione di sicurezza? In che modo Tor protegge contro un utente malintenzionato che esegue solo migliaia di nodi?

score 9 · Accepted Answer

Le variabili di ambiente sono il modo migliore per farlo, in particolare il metodo 2. Docker, per impostazione predefinita, non consente a se stesso di essere eseguito da utenti diversi da root. L'accesso alla presa è proibito. Direi che il metodo 2 è ragionevolmente sicuro, dato che, se un utente malintenzionato ha un accesso root (e può attirare l'attenzione nei contenitori della finestra mobile), si è già messi male.

Due note di sicurezza Docker in generale. Sii super cauto nell'abilitare l'API, poiché per impostazione predefinita non esiste crittografia o autenticazione. Hanno un modo di usare certs e TLS che hanno documentato, ma procedono con cautela.

Inoltre, se possibile abilita SELinux sul tuo server. Le versioni più recenti di esso sono in grado di visualizzare effettivamente i contenitori di finestra mobile e creare automaticamente contesti di sicurezza per ciascuno di essi. Ciò impedisce a un container di scendere facilmente dall'host. Di default la finestra mobile viene eseguita come utente root e, anche con la direttiva USER, si interfaccia ancora direttamente con il kernel, diversamente da una VM. Ciò espone l'host a qualsiasi exploit di privilegi locali non appena un contenitore di finestra mobile viene compromesso.