Entopia insufficiente per supportare/dev/random nei contenitori docker in esecuzione in boot2docker

Question

L'esaurimento dell'entropia nei sistemi Linux virtualizzati sembra essere un problema comune (ad esempio /dev/random Extremely Slow?, Getting linux to buffer /dev/random). Nonostante l'uso di un generatore di numeri casuali dell'hardware (HRNG) è spesso suggerito l'uso di un demone di raccolta entropico come HAVEGED. Tuttavia un daemon di raccolta entropico (EGD) non può essere eseguito all'interno di un contenitore Docker, deve essere fornito dall'host.

L'utilizzo di un EGD funziona bene per gli host di docker basati su distribuzioni Linux come Ubuntu, RHEL, ecc. Il fatto di far funzionare un demone all'interno di boot2docker, basato su Tiny Core Linux (TCL), sembra essere un'altra storia. Sebbene TCL abbia un meccanismo di estensione, un'estensione per un daemon di raccolta entropia doesn't seem to be available.

Quindi un EGD sembra una soluzione adeguata per l'esecuzione di contenitori docker in un ambiente di hosting (di produzione), ma come risolverlo per lo sviluppo/test in boot2docker?

Poiché eseguire un EGD in boot2docker sembrava troppo difficile, ho pensato semplicemente di usare/dev/urandom invece di/dev/random. L'uso di/dev/urandom è un po 'meno sicuro, ma comunque valido per la maggior parte delle applicazioni che non generano chiavi crittografiche a lungo termine. Almeno dovrebbe andare bene per lo sviluppo/test all'interno di boot2docker.

Answer 1

Poiché non mi è piaciuto modificare i contenitori Docker per lo sviluppo/test, ho provato a modificare l'immagine boot2docker. Fortunatamente, l'immagine boot2docker è compilata con Docker e può essere facilmente extended. Così ho creato la mia build Docker boot2docker-urandom. Estende l'immagine boot2docker standard con una regola udev trovata here.

Costruire la propria immagine boot2docker.iso è semplice come

$ docker run --rm mbonato/boot2docker-urandom > boot2docker.iso 

Per sostituire lo standard boot2docker.iso che viene fornito con boot2docker è necessario:

$ boot2docker stop 
$ boot2docker delete 
$ mv boot2docker.iso ~/.boot2docker/ 
$ boot2docker init 
$ boot2docker up 

Edit:

Tuttavia, all'interno di un contenitore Docker/dev/blocchi casuali. Molto probabilmente, perché i contenitori Docker non usano direttamente/dev/random dell'host, ma usano il dispositivo kernel corrispondente - che ancora blocca.

Qualche suggerimento?

Answer 2

Ho appena realizzato, che è semplice da montare/dev/urandom dall'host come/dev/random nel contenitore:

$ docker run -v /dev/urandom:/dev/random ... 

Il risultato è come previsto:

$ docker run --rm -it -v /dev/urandom:/dev/random ubuntu dd if=/dev/random of=/dev/null bs=1 count=1024 
1024+0 records in 
1024+0 records out 
1024 bytes (1.0 kB) copied, 0.00223239 s, 459 kB/s 

Almeno so come costruire le mie immagini boot2docker ora ;-)

Answer 3

Alpine Linux potrebbe essere una scelta migliore per un host leggero docker.Alpine LXC & docker immagini sono solo 5 MB (contro i 27MB per boot2docker)

Io uso haveged su Alpine per LXC ospiti & su Debian per docker ospiti. Fornisce abbastanza entropia per generare i certificati gpg/ssh & openssl nei contenitori. Alpine now has an official docker repo.

In alternativa, creare un pacchetto haveged per Tiny Core - è disponibile un package build system.

Answer 4

Un'altra opzione è quella di installare i RNG-tools pacchetto e la mappa di usare il/dev/urandom

yum install rng-tools 
    rngd -r /dev/urandom 

Con questo non ho avuto bisogno di mappare qualsiasi volume nel contenitore finestra mobile.

Answer 5

La soluzione più elegante che ho trovato è in esecuzione Haveged in contenitore separato:

docker pull harbur/haveged 
docker run --privileged -d harbur/haveged 

Verificare se abbastanza entropia disponibili:

$ cat /proc/sys/kernel/random/entropy_avail 
2066