Cum să obțineți suficientă entropie în containerele Docker?

Ori de câte ori eu cat /proc/sys/kernel/random/entropy_avail în interiorul containerelor mele Docker (bazat pe Linux 5.10), obțin un rezultat cu două cifre, care aparent este ridicol de scăzut.Se presupune că orice lucru sub 4 cifre este rău, iar menținerea acestuia aproape de 4096 (max.) este ideal.

Am citit despre un demon care aduna entropie numit haveged, dar se presupune că este învechit de la Linux kernel 5.6, așa că nu mai sunt sigur că aceasta este soluția potrivită.

De ce este entropia mea atât de scăzută în interiorul containerelor mele Docker care rulează nucleul 5.10 și ce pot face pentru a o remedia?

Am descoperit inițial acest lucru când un script Python „citatul zilei” a tot ales aceleași câteva citate. Nu am însămânțat manual modulul aleatoriu standard al lui Python, dar conform documentației și codului sursă, ar trebui să se auto-sedeze din entropia sistemului (direct prin getentropie (3) sau obține aleatoriu (2) dacă sunt disponibile, ceea ce presupun că ar fi într-un mediu Linux modern tipic, sau prin /dev/random sau /dev/urandom în caz contrar, sau reveniți la utilizarea orei sistemului și a PID-ului ca ultimă soluție). Deci presupun că entropia mea era atât de scăzută încât getentropie (3) a fost returnarea entropiei slabe? Oricum, însămânțarea manuală a modulului aleatoriu al lui Python cu ora sistemului a rezolvat această problemă.

Cu toate acestea, acum sunt îngrijorat că serverele mele web care fac TLS și serverele mele de autentificare, care rulează toate în containere Docker similare, ar putea să nu aibă suficientă entropie pentru a genera chei puternice și pad-uri unice și provocări și altele. Așa că vreau să ajung la fundul modului de a garanta că containerele mele Docker primesc suficientă entropie pentru a-și face treaba bine.

Aceasta nu este o infrastructură națională critică sau ceva în care instalarea unui modul RNG hardware ar fi adecvată. Acestea sunt doar containere Docker găzduite în cloud, așa că sper să o pot implementa în containerele/imaginile mele Docker.

Din moment ce vorbiți cu nucleul, nu are deloc legătură cu docker:

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

$ docker run -it --rm busybox cat /proc/sys/kernel/random/entropy_avail
3781

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

Dacă obțineți mai multă entropie pe gazdă, veți avea mai multă entropie în container.

Anecdotele că ați văzut același citat al zilei recent nu sunt o dovadă că RNG-ul dvs. are o problemă.

Utilizați Python's Random (nu SystemRandom) pentru tot ceea ce nu este criptografia critică pentru securitate. Semințele în sine în mod implicit. Rețineți că orice număr întreg rezonabil de unic ar funcționa ca sămânță, extraordinar de puțin probabil ca calitatea unui RNG să poată fi detectată prin însămânțarea altuia.

Dar SystemRandom? Acesta este API-ul Python pentru a obține RNG-uri specifice platformei care nu sunt deterministe și, prin urmare, mai bune pentru utilizarea criptografică.

Biții aleatorii nu sunt rari sau speciali pe Linux, acesta este un mit. CSPRNG al nucleului este bun și, odată inițializat, poate fi folosit în modul neblocant (/dev/urandom, getrandom cu GRND_NONBLOCK) pentru cantități mari de biți aleatori. De fapt, din 5.6, așa funcționează, Linux nu mai are un pool de blocare. /dev/random se blochează numai la boot înainte de inițializarea kernel rng. Pe termen lung, aceasta este o soluție reală, upgrade kernel-ul și programele pot avea câte biți doresc.

Problema este că oamenii încă cred că API-urile de blocare sunt mai bune, în ciuda refuzului serviciului care o cauzează atunci când un pool de blocare este epuizat. Python a remediat o problemă cu epuizarea pool-ului de blocare într-un script de pornire timpurie... prin blocarea os.urandom() pe Linux. Suspin.