Как получить достаточно энтропии в контейнерах Docker?

Всякий раз, когда я кошка /proc/sys/kernel/random/entropy_avail внутри моих контейнеров Docker (на основе Linux 5.10) я получаю двузначный результат, что, по-видимому, смехотворно мало.Предположительно все, что меньше 4 цифр, плохо, и идеально держать его близко к 4096 (максимум).

Я читал о демоне сбора энтропии под названием иметь, но он предположительно устарел, начиная с ядра Linux 5.6, поэтому я больше не уверен, что это правильное решение.

Почему у меня такая низкая энтропия внутри контейнеров Docker с ядром 5.10 и что я могу сделать, чтобы это исправить?

Первоначально я обнаружил это, когда скрипт Python «цитата дня» продолжал выбирать одни и те же несколько цитат. Я не задавал вручную стандартный модуль Python Random, но, согласно его документации и исходному коду, он должен заполнять себя из системной энтропии (непосредственно через гетэнтропия (3) или получить получитьслучайно(2) если они доступны, что я предполагаю, они будут в типичной современной среде Linux или через /dev/случайный или же /dev/urandom в противном случае или вернуться к использованию системного времени и PID в качестве крайней меры). Так что я предполагаю, что моя энтропия была настолько низкой, что гетэнтропия (3) возвращал плохую энтропию? В любом случае, ручное заполнение модуля Python Random системным временем решило эту проблему.

Однако теперь меня беспокоит, что мои веб-серверы, использующие TLS, и мои серверы аутентификации, работающие в одинаковых контейнерах Docker, могут не иметь достаточной энтропии для генерации надежных ключей, одноразовых блокнотов, задач и многого другого. Итак, я хочу разобраться, как гарантировать, что мои контейнеры Docker получают достаточно энтропии, чтобы хорошо выполнять свою работу.

Это не критическая национальная инфраструктура или что-то, где установка аппаратного модуля ГСЧ была бы уместной. Это всего лишь размещенные в облаке контейнеры Docker, поэтому я надеюсь найти решение, которое смогу реализовать в своих контейнерах/образах 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

Если вы получите больше энтропии на хосте, у вас будет больше энтропии в контейнере.

Анекдоты о том, что вы недавно видели одну и ту же цитату дня, не являются доказательством того, что у вашего генератора случайных чисел есть проблема.

Используйте Python Random (не SystemRandom) для всего, кроме критически важной для безопасности криптографии. Сидит сам по умолчанию. Обратите внимание, что в качестве начального числа подойдет любое достаточно уникальное целое число, что чрезвычайно маловероятно, что качество ГСЧ может быть обнаружено путем заполнения другого.

Как насчет SystemRandom? Это API Python для получения специфичных для платформы RNG, которые не являются детерминированными и поэтому лучше подходят для криптографического использования.

Случайные биты не являются чем-то редким или особенным в Linux, это миф. CSPRNG ядра хорош, и после инициализации его можно использовать в неблокирующем режиме (/dev/urandom, getrandom с GRND_NONBLOCK) для большого количества случайных битов. Собственно с 5.6 так и работает, В Linux больше нет блокирующего пула. /dev/random блокируется только при загрузке до инициализации rng ядра. В долгосрочной перспективе это реальное решение, обновите ядро, и программы могут иметь столько бит, сколько захотят.

Проблема в том, что люди по-прежнему думают, что блокирующие API лучше, несмотря на отказ в обслуживании, который возникает, когда блокирующий пул исчерпан. Python исправил проблему с исчерпанием пула блокировок в скрипте ранней загрузки... сделав блокировку os.urandom() в Linux. Вздох.