Whenever I cat /proc/sys/kernel/random/entropy_avail inside my Docker containers (Linux 5.10 based), I get a double-digit result, which is apparently laughably low. Supposedly anything below 4 digits is bad, and keeping it close to 4096 (the max) is ideal.
I've read about an entropy-gathering daemon called haveged, but it is supposedly obsolete since Linux kernel 5.6, so I'm not sure that that's the right solution anymore.
Why is my entropy so low inside my Docker containers running the 5.10 kernel, and what can I do to fix it?
I originally discovered this when a Python "quote of the day" script kept choosing the same few quotes. I wasn't manually seeding Python's standard Random module, but according to its documentation and source code, it's supposed to self-seed from system entropy (directly via getentropy(3) or get getrandom(2) if available, which I assume they would be on a typical modern Linux environment, or via /dev/random or /dev/urandom otherwise, or fall back to using the system time and PID as a last resort). So I guess my entropy was so low that getentropy(3) was returning poor entropy? Anyway, manually seeding Python's Random module with the system time worked around that problem.
However, now I'm worried that my web servers doing TLS, and my authentication servers, all of which run in similar Docker containers, might not have enough entropy to generate strong keys and one-time-pads and challenges and whatnot. So I want to get to the bottom of how to guarantee that my Docker containers are getting enough entropy to do their jobs well.
This isn't critical national infrastructure or something where installing a hardware RNG module would be appropriate. These are just cloud-hosted Docker containers, so I'm hoping for a solution I can implement within my Docker containers/images.