latest - No hay suficiente entropía para admitir/dev/random en contenedores acoplables que se ejecutan en boot2docker

docker tag example

Question

Quedarse sin entropía en sistemas Linux virtualizados parece ser un problema común (p . Ej., / Dev / random Extremadamente lento?, Obtener linux para almacenar en búfer / dev / random ). A pesar de utilizar un generador de números aleatorios de hardware (HRNG), a menudo se sugiere el uso de un daemon de recopilación de entropía como HAVEGED . Sin embargo, un daemon de recopilación de entropía (EGD) no se puede ejecutar dentro de un contenedor Docker, debe ser proporcionado por el host.

Usar un EGD funciona bien para los docker basados ​​en distribuciones de Linux como Ubuntu, RHEL, etc. Conseguir que un daemon funcione dentro de boot2docker, que está basado en Tiny Core Linux (TCL), parece ser otra historia. Aunque TCL tiene un mecanismo de extensión, una extensión para un daemon de reunión de entropía no parece estar disponible .

Entonces, un EGD parece una solución adecuada para ejecutar contenedores Docker en un entorno de hosting (producción), pero ¿cómo resolverlo para su desarrollo / prueba en boot2docker?

Dado que ejecutar un EGD en boot2docker parecía demasiado difícil, pensé en simplemente usar / dev / urandom en lugar de / dev / random. El uso de / dev / urandom es un poco menos seguro, pero todavía está bien para la mayoría de las aplicaciones que no generan claves criptográficas a largo plazo. Al menos debería estar bien para desarrollo / prueba dentro de boot2docker.

Answer 1

Como no deseaba modificar mis contenedores Docker para desarrollo / prueba, traté de modificar la imagen de boot2docker. Afortunadamente, la imagen de boot2docker está construida con Docker y se puede extended fácilmente. Así que configuré mi propia compilación Docker boot2docker-urandom . Extiende la imagen estándar boot2docker con una regla udev que se encuentra here .

Construir su propia imagen boot2docker.iso es simple como

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

Para reemplazar el estándar boot2docker.iso que viene con boot2docker, necesitas:

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

Editar:

Sin embargo , desde el interior de un contenedor Docker / dev / random still blocks. Lo más probable es que los contenedores Docker no usen / dev / random del host directamente, sino que utilicen el dispositivo kernel correspondiente, que aún bloquea.

¿Alguna sugerencia?

Answer 2

La solución más elegante que he encontrado es ejecutar Haveged en un contenedor separado:

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

Compruebe si hay suficiente entropía disponible:

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

Answer 3

Me acabo de dar cuenta de que es simple como montar / dev / urandom desde el host como / dev / random en el contenedor:

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

El resultado es el esperado:

$ 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

Al menos sé cómo construir mis propias imágenes boot2docker ahora ;-)

Answer 4

Otra opción es instalar el paquete rng-tools y asignarlo para usar / dev / urandom

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

Con esto no tuve que mapear ningún volumen en el contenedor acoplable.

Answer 5

Alpine Linux puede ser una mejor opción para un host de docker liviano. Las imágenes de Alpine LXC y docker son solo de 5mb (frente a 27mb para boot2docker )

Utilizo haveged en Alpine para invitados de LXC y en Debian para invitados de docker . Da suficiente entropía para generar claves gpg / ssh y certificados openssl en contenedores. Alpine ahora tiene un repositorio oficial de docker .

haveged construya un paquete haveged para Tiny Core: hay un sistema de compilación de paquetes disponible.