How to improve random number generation in kubernetes cluster containers?

5/10/2019

I'm seeing some issues with random number generation inside containers running in a kubernetes cluster (repeated values). It might be the lack of entropy inside the container, or it could be something else, on a higher level, but I'd like to investigate the entropy angle and I have a few questions I'm having trouble finding the answers to.

  • The value of /proc/sys/kernel/random/entropy_avail is between 950 and 1050 across containers and nodes - is that good enough? rngtest -c 10000 </dev/urandom returns pretty good results - FIPS 140-2 successes: 9987, FIPS 140-2 failures: 13, but run against /dev/random it just hangs forever.

  • The entropy_avail values in containers seem to follow the values on the nodes. If I execute cat /dev/random >/dev/null on the node, entropy_avail drops also inside the containers running on that node, even though docker inspect doesn't indicate that the /dev/*random devices are bind-mounted from the node. So how do they relate? Can one container consume the entropy available to other containers on that node?

  • If entropy_avail around 1000 is something to be concerned about, what's the best way of increasing that value? It seems deploying a haveged daemonset would be one way (https://github.com/kubernetes/kubernetes/issues/60751). Is that the best/simplest way to go about it?

I'm having trouble finding the answers on google, stackoverflow, and in kubernetes github issues. I also got no response in the kubernetes-users slack channel, so I'm hoping someone here can shed some light on this.

Proper pseudo-random number generation underpins all cryptographic operations, so any kubernetes user should be interested in the answers.

Thanks in advance.

-- brwk
cryptography
docker
entropy
kubernetes
random

0 Answers