Как получить достаточно энтропии в контейнерах Docker?
Всякий раз, когда я cat /proc/sys/kernel/random/entropy_availвнутри своих контейнеров Docker (на базе Linux 5.10), я получаю двузначный результат-, что, по-видимому, смехотворно мало. Предположительно, все, что меньше 4 цифр, является плохим, и идеально держать его близко к 4096 (max).
Я читал о демоне сбора энтропии-под названием haveged, но он предположительно устарел с версии ядра Linux 5.6, поэтому я не уверен, что это правильное решение.
Почему у меня такая низкая энтропия в моих контейнерах Docker с ядром 5.10 и что я могу сделать, чтобы это исправить?
Впервые я обнаружил это, когда Python-скрипт «цитата дня» продолжал выбирать одни и те же несколько цитат. Я не заполнял вручную стандартный модуль Python Random, но, согласно его документации и исходному коду, он должен сам-задавать из системной энтропии (непосредственно через getentropy(3)или получать getrandom(2), если он доступен, что я предполагаю они будут в типичной современной среде Linux, или через /dev/randomили /dev/urandomиным образом, или вернуться к использованию системного времени и PID в качестве крайней меры). Итак, я предполагаю, что моя энтропия была настолько низкой, что getentropy(3)возвращал плохую энтропию? В любом случае, ручное заполнение модуля Python Random системным временем решило эту проблему.
Однако теперь я обеспокоен тем, что мои веб-серверы, использующие TLS, и мои серверы аутентификации, работающие в одинаковых контейнерах Docker, могут не иметь достаточной энтропии для генерации надежных ключей и одноразовых-временных-блокнотов. и вызовы и прочее. Итак, я хочу разобраться, как гарантировать, что мои контейнеры Docker получают достаточно энтропии, чтобы хорошо выполнять свою работу.
Это не критическая национальная инфраструктура или что-то, где установка аппаратного модуля ГСЧ была бы уместной. Это всего лишь облачные-контейнеры Docker, поэтому я надеюсь найти решение, которое смогу реализовать в своих контейнерах/образах Docker.
Анекдоты о том, что вы недавно видели одну и ту же цитату дня, не являются доказательством того, что ваш ГСЧ есть проблема.
Используйте Python's Random (, а не SystemRandom)для всего, кроме критичной с точки зрения безопасности криптографии. Сидит сам по умолчанию. Обратите внимание, что в качестве начального числа подойдет любое достаточно уникальное целое число, что чрезвычайно маловероятно, что качество ГСЧ может быть обнаружено путем заполнения другого.
А как насчет SystemRandom? Это API Python для получения специфичных для платформы RNG, которые не являются детерминированными и поэтому лучше подходят для криптографического использования.
Случайные биты не являются чем-то редким или особенным в Linux, это миф. CSPRNG ядра хорош и после инициализации может использоваться в неблокирующем режиме (/dev/urandom, getrandom с GRND_NONBLOCK)для большого количества случайных битов. На самом деле, начиная с 5.6, вот как это работает, Linux больше не имеет блокирующего пула . /dev/random блокируется только при загрузке до инициализации rng ядра. В долгосрочной перспективе это реальное решение, обновите ядро, и программы могут иметь столько бит, сколько захотят.
Проблема в том, что люди по-прежнему думают, что блокирующие API лучше, несмотря на отказ в обслуживании, который возникает, когда блокирующий пул исчерпан. Python устранил проблему с исчерпанием пула блокировок в скрипте ранней загрузки... , создав блокировку os.urandom()в Linux . Вздох.
Поскольку вы говорите с ядром, на самом деле это никак не связано с докером.:
$ 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
Если вы получаете больше энтропии на хосте, у вас будет больше энтропии в контейнере.