Исчезновение энтропии в виртуализированных системах Linux, похоже, является распространенной проблемой (например, qaru.site/info/144420/... Получение linux в буфер /dev/random). Несмотря на использование аппаратного генератора случайных чисел (HRNG), часто предлагается использовать демон сбора энтропии, такой как HAVEGED. Однако демон сбора энтропии (EGD) не может быть запущен внутри контейнера Docker, он должен быть предоставлен хостом.
Использование EGD прекрасно работает для узлов докеров, основанных на дистрибутивах Linux, таких как Ubuntu, RHEL и т.д. Получение такого демона для работы внутри boot2docker, основанного на Tiny Core Linux (TCL), кажется другой историей. Хотя TCL имеет механизм расширения, расширение для демона сбора энтропии , по-видимому, недоступно.
Таким образом, EGD кажется правильным решением для запуска докер-контейнеров в (производственной) среде хостинга, но как решить эту проблему для разработки/тестирования в boot2docker?
Поскольку запуск EGD в boot2docker показался слишком сложным, я подумал о том, чтобы просто использовать /dev/urandom вместо /dev/random. Использование /dev/urandom немного менее безопасно, но все же хорошо для большинства приложений, которые не генерируют долгосрочные криптографические ключи. По крайней мере, это должно быть хорошо для разработки/тестирования внутри boot2docker.
Я просто понял, что это просто, как установка /dev/urandom из хоста в качестве /dev/random в контейнер:
$ docker run -v /dev/urandom:/dev/random ...
Результат будет таким, как ожидалось:
$ docker run --rm -it -v /dev/urandom:/dev/random ubuntu dd if=/dev/random of=/dev/null bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB) copied, 0.00223239 s, 459 kB/s
По крайней мере, я знаю, как теперь создавать свои собственные загрузочные файлы, -)
Самое элегантное решение, которое я нашел, работает в отдельном контейнере:
docker pull harbur/haveged
docker run --privileged -d harbur/haveged
Проверьте наличие достаточной энтропии:
$ cat /proc/sys/kernel/random/entropy_avail
2066
Поскольку я не любил модифицировать свои контейнеры Docker для разработки/тестирования, я попытался изменить образ boot2docker. К счастью, образ boot2docker собран с помощью Docker и может быть легко расширен. Итак, я настроил свою собственную сборку Docker boot2docker-urandom. Он расширяет стандартный образ boot2docker правилом udev, найденным здесь.
Создать свой собственный образ boot2docker.iso просто
$ docker run --rm mbonato/boot2docker-urandom > boot2docker.iso
Чтобы заменить стандартный boot2docker.iso, который поставляется с boot2docker, вам необходимо:
$ boot2docker stop
$ boot2docker delete
$ mv boot2docker.iso ~/.boot2docker/
$ boot2docker init
$ boot2docker up
Ограничения внутри контейнера Docker/dev/random все еще блокируют. Скорее всего, потому что контейнеры Docker не используют /dev/random хоста напрямую, а используют соответствующее устройство ядра - которое все еще блокирует.
Alpine Linux может быть лучшим выбором для легкого хоста docker. Изображения Alpine LXC и docker составляют всего 5 мб (против 27 мб для boot2docker)
Я использую haveged в Alpine для гостей LXC и гостей Debian для docker. Он дает достаточно энтропии для генерации ключей gpg/ssh и сертификатов openssl в контейнерах. Теперь у Alpine есть официальное репо docker.
Альтернативно создайте пакет haveged для Tiny Core - существует система сборки пакетов.
Другой вариант - установить пакет rng-tools и сопоставить его с использованием /dev/urandom
yum install rng-tools
rngd -r /dev/urandom
С этим мне не нужно было отображать любой том в контейнере докера.
если у вас есть эта проблема в док-контейнере, созданном из собственного образа, который запускает приложение Java (например, созданный FROM tomcat:alpine) и не имеет доступа к хосту (например, в управляемом кластере k8s), вы можете добавить следующая команда в ваш dockerfile для использования неблокирующего SecureRandom:
RUN sed -i.bak \
-e "s/securerandom.source=file:\/dev\/random/securerandom.source=file:\/dev\/urandom/g" \
-e "s/securerandom.strongAlgorithms=NativePRNGBlocking/securerandom.strongAlgorithms=NativePRNG/g" \
$JAVA_HOME/lib/security/java.security
два выражения регулярных выражений заменяют file: /dev/random на file: /dev/urandom и NativePRNGBlocking NativePRNG в файле $JAVA_HOME/lib/security/java.security который заставляет tomcat $JAVA_HOME/lib/security/java.security достаточно быстро. я не проверял, работает ли это также на не-альпийских изображениях openjdk, но если команда sed не работает, просто проверьте расположение файла java.security внутри контейнера и соответствующим образом java.security путь.
примечание: в jdk11 путь был изменен на $JAVA_HOME/conf/security/java.security