Not enough entropy to support /dev/random in docker containers running in boot2docker

Running out of entropy in virtualized Linux systems seems to be a common problem (e.g. https://stackoverflow.com/questions/4819359/dev-random-extremely-slow, https://stackoverflow.com/questions/5633877/getting-linux-to-buffer-dev-random). Despite of using a hardware random number generator (HRNG) the use of a an entropy gathering daemon like HAVEGED is often suggested. However an entropy gathering daemon (EGD) cannot be run inside a Docker container, it must be provided by the host.

Using an EGD works fine for docker hosts based on linux distributions like Ubuntu, RHEL, etc. Getting such a daemon to work inside boot2docker - which is based on Tiny Core Linux (TCL) - seems to be another story. Although TCL has a extension mechanism, an extension for an entropy gathering daemon doesn't seem to be available.

So an EGD seems like a proper solution for running docker containers in a (production) hosting environment, but how to solve it for development/testing in boot2docker?

Since running an EGD in boot2docker seemed too difficult, I thought about simply using /dev/urandom instead of /dev/random. Using /dev/urandom is a litte less secure, but still fine for most applications which are not generating long-term cryptographic keys. At least it should be fine for development/testing inside boot2docker.

I just realized, that it is simple as mounting /dev/urandom from the host as /dev/random into the container:

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

The result is as expected:

$ 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

At least I know how to build my own boot2docker images now ;-)

The most elegant solution I've found is running Haveged in separate container:

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

Check whether enough entropy available:

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

Another option is to install the rng-tools package and map it to use the /dev/urandom

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

With this I didn't need to map any volume in the docker container.

Since I didn't like to modify my Docker containers for development/testing I tried to modify the boot2docker image. Luckily, the boot2docker image is build with Docker and can be easily extended. So I've set up my own Docker build boot2docker-urandom. It extends the standard boot2docker image with a udev rule found here.

Building your own boot2docker.iso image is simple as

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

To replace the standard boot2docker.iso that comes with boot2docker you need to:

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

Limitations, from inside a Docker container /dev/random still blocks. Most likely, because the Docker containers do not use /dev/random of the host directly, but use the corresponding kernel device - which still blocks.

Alpine Linux may be a better choice for a lightweight docker host. Alpine LXC & docker images are only 5mb (versus 27mb for boot2docker)

I use haveged on Alpine for LXC guests & on Debian for docker guests. It gives enough entropy to generate gpg / ssh keys & openssl certificates in containers. Alpine now has an official docker repo.

Alternatively build a haveged package for Tiny Core - there is a package build system available.

if you have this problem in a docker container created from a self-built image that runs a java app (e.g. created FROM tomcat:alpine) and don't have access to the host (e.g. on a managed k8s cluster), you can add the following command to your dockerfile to use non-blocking seeding of SecureRandom:

RUN sed -i.bak \
  -e "s/securerandom.source=file:\/dev\/random/securerandom.source=file:\/dev\/urandom/g" \
  -e "s/securerandom.strongAlgorithms=NativePRNGBlocking/securerandom.strongAlgorithms=NativePRNG/g" \
  $JAVA_HOME/lib/security/java.security

the two regex expressions replace file:/dev/random by file:/dev/urandom and NativePRNGBlocking by NativePRNG in the file $JAVA_HOME/lib/security/java.security which causes tomcat to startup reasonably fast on a vm. i haven't checked whether this works also on non alpine-based openjdk images, but if the sed command fails, just check the location of the file java.security inside the container and adapt the path accordingly.

note: in jdk11 the path has changed to $JAVA_HOME/conf/security/java.security