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

Question

Running out of entropy in virtualized Linux systems seems to be a common problem (e.g. /dev/random Extremely Slow?, Getting linux to buffer /dev/random). Despite of using a

Answer 1

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 ;-)

Answer 2

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

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.