Nicht genug Entropie, um/dev/random in Docker-Containern zu unterstützen, die in boot2docker laufen

Question

Das Entropieproblem in virtualisierten Linux-Systemen scheint ein häufiges Problem zu sein (z. B. /dev/random Extremely Slow?, Getting linux to buffer /dev/random). Trotz der Verwendung eines Hardware-Zufallszahlengenerators (HRNG) wird oft die Verwendung eines Entropieerfassungsdämons wie HAVEGED vorgeschlagen. Ein Entropy Rally Daemon (EGD) kann jedoch nicht innerhalb eines Docker-Containers ausgeführt werden, sondern muss vom Host bereitgestellt werden.

Die Verwendung eines EGD funktioniert gut für Docker-Hosts auf Basis von Linux-Distributionen wie Ubuntu, RHEL usw. Einen solchen Daemon in boots2docker zu verwenden, der auf Tiny Core Linux (TCL) basiert, scheint eine andere Geschichte zu sein. Obwohl TCL über einen Erweiterungsmechanismus verfügt, handelt es sich um eine Erweiterung für einen Entropy Rally Daemon doesn't seem to be available.

So ein EGD scheint eine richtige Lösung für den Betrieb Docker Container in einer (Produktion) Hosting-Umgebung, aber wie es für die Entwicklung/Tests in boot2docker zu lösen?

Da das Starten eines EGD in boot2docker zu schwierig schien, dachte ich daran, einfach/dev/urandom anstelle von/dev/random zu verwenden. Die Verwendung von/dev/urandom ist ein wenig weniger sicher, aber immer noch gut für die meisten Anwendungen, die keine langfristigen kryptografischen Schlüssel generieren. Zumindest sollte es für die Entwicklung/Tests innerhalb von boot2docker in Ordnung sein.

Answer 1

Da ich meine Docker-Container für Entwicklung/Tests nicht ändern wollte, habe ich versucht, das Boot2docker-Image zu ändern. Glücklicherweise wird das Boot2docker-Image mit Docker erstellt und kann einfach extended sein. Also habe ich meinen eigenen Docker Build boot2docker-urandom eingerichtet. Es erweitert das Standard-Boot2docker-Image um eine udev-Regel, die here gefunden wurde.

Ihr eigenes boot2docker.iso Bild Gebäude ist einfach wie

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

den Standard zu ersetzen boot2docker.iso dass mit boot2docker kommt Sie benötigen:

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

Edit:

Allerdings, von innen ein Docker Container/Dev/Random noch blockiert. Höchstwahrscheinlich, weil die Docker-Container nicht direkt den/dev/random des Hosts verwenden, sondern das entsprechende Kernel-Gerät - welches immer noch blockiert.

Irgendwelche Vorschläge?

Answer 2

ich gerade festgestellt, dass es als Montage/dev/urandom vom Host als/dev/random in den Behälter einfach:

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

Das Ergebnis wie erwartet:

$ 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 

Zumindest weiß ich, wie ich meine eigenen boot2docker Bilder jetzt bauen kann ;-)

Answer 3

Alpine Linux könnte eine bessere Wahl für einen leichten docker Host sein.Alpine LXC & docker Bilder sind nur 5 MB (im Vergleich zu 27MB für boot2docker)

Ich benutze haveged auf Alpine für LXC Gäste & auf Debian für docker Gäste. Es gibt genug Entropie, um gpg/ssh Schlüssel & openssl Zertifikate in Containern zu erzeugen. Alpine now has an official docker repo.

Alternativ können Sie ein haveged Paket für Tiny Core erstellen - es ist ein package build system verfügbar.

Answer 4

Eine weitere Option ist die rng-tools Paket zu installieren und wo es das/dev/urandom

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

Damit verwenden ich kein Volumen im Docker Behälter zur Karte brauchte.

Answer 5

Die eleganteste Lösung, die ich gefunden habe Haveged in separaten Behälter ausgeführt wird:

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

Überprüfen Sie, ob genügend Entropie zur Verfügung:

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