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 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.

Britney

openssl user urandom. What are you doing that requires more? – Owenowena

Some Java cryptographic providers relay on /dev/random (e.g. for secure random number generation). – Britney

I agree you can't always control that. In any case, here you've got some additional info about java SecureRandom vs /dev/[u]random - bugs.openjdk.java.net/browse/JDK-4705093 – Owenowena

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

Britney

The impacts on security by using /dev/urandom instead of /dev/random on development machines should be quite limited. – Britney

"Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems." 2uo.de/myths-about-urandom – Monofilament

What about cross-platform compatibility, i.e. for those poor souls running Windows? – Domela

I've tried a lot of the rng-tools/haveged suggestions and this is the only one that worked. Thanks! – Cacia

@Domela docker-toolbox for Windows still runs on linux, and docker for Windows 10+ runs on the linux subsystem (if I understood correctly), so that should still work? – Streamlet

This is the same as running ln -s /dev/urandom /dev/random inside the container. /dev/random and /dev/urandom are always mapped to host. – Streamlet

See this answer for more info – Streamlet

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

Pood

Answer 3

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.

Capitol

This gives me this message: unable to adjust write_wakeup_threshold: Read-only file system – Polypropylene

Run it on the docker host, not in the container. – Amphitryon

Answer 4

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.

Britney

Answer 5

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

Outturn

too base this technique does not work with openjdk11 as the java.security file does not exist. – Recite

@ArchimedesTrajano: I use openjdk from adoptopenjdk.net (for my own use currently Java8, but for an experiment today Jdk11). After downloading and extracting Jdk11 from this site, I ran the command $ grep -r securerandom *, which gave me the path conf/security/java.security (relative path below the Jdk home directory). I hope this helps. – Outturn

I'm talking specifically about the openjdk:11-slim image from docker hub but hopefully it is in the same spot as you said – Recite

@ArchimedesTrajano: just in case: enter an openjdk:11-slim-container as follows: $ docker run --rm -it openjdk:11-slim bash, then $ cd / (just to make sure you are in the root directory), then $ grep -r securerandom * which gives here: etc/java-11-openjdk/security/java.security (the search takes a while, but you can stop it using Ctrl+C, then exit using Ctrl+D). this would most likely work also in other containers based on images that contains a jvm. – Outturn

Answer 6

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.

Walrath