熵不足，无法在boot2docker中运行的docker容器中支持/dev/random

在虚拟化Linux系统中耗尽熵似乎是一个常见的问题（例如）。尽管使用了硬件随机数生成器（HRNG），但经常建议使用类似于熵收集守护进程的方法。但是，熵收集守护程序（EGD）不能在Docker容器内运行，它必须由主机提供

使用EGD对于基于linux发行版的docker主机（如Ubuntu、RHEL等）来说效果很好。让这样一个守护进程在基于Tiny Core linux（TCL）的boot2docker中工作似乎是另一回事。尽管TCL有一个扩展机制，但它是一个熵收集守护进程的扩展

因此，EGD似乎是在（生产）托管环境中运行docker容器的合适解决方案，但是如何在boot2docker中为开发/测试解决它呢

---

因为在boot2docker中运行EGD似乎太难了，所以我考虑简单地使用/dev/uradom而不是/dev/random。使用/dev/uradom的安全性稍差，但对于大多数不生成长期加密密钥的应用程序来说仍然很好。至少对于boot2docker内部的开发/测试来说应该是不错的

因为我不喜欢修改Docker容器进行开发/测试，所以我尝试修改boot2docker映像。幸运的是，boot2docker映像是用Docker构建的，可以很容易地实现。所以我建立了自己的Docker构建。它使用找到的udev规则扩展标准boot2docker映像

构建自己的boot2docker.iso映像非常简单

$ docker run --rm mbonato/boot2docker-urandom > boot2docker.iso

要替换boot2docker附带的标准boot2docker.iso，您需要：

$ boot2docker stop
$ boot2docker delete
$ mv boot2docker.iso ~/.boot2docker/
$ boot2docker init
$ boot2docker up

---

限制，从Docker容器内部/dev/random仍然阻塞。最有可能的原因是Docker容器不直接使用主机的/dev/random，而是使用相应的内核设备，这仍然会阻塞。

我刚刚意识到，将/dev/urandom作为/dev/random从主机装载到容器中非常简单：

$ docker run -v /dev/urandom:/dev/random ...

docker pull harbur/haveged
docker run --privileged -d harbur/haveged

结果如预期：

$ 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

至少我现在知道如何构建自己的boot2docker映像；-）

对于轻量级

docker

主机，可能是更好的选择。阿尔卑斯

LXC

和

docker

图像只有5mb（而

boot2docker

的图像只有27mb）

对于

LXC

guests，我使用

haveged

on；对于

docker

guests，我使用Debian。它提供了足够的熵来在容器中生成

gpg

/

ssh

密钥和

openssl

证书

---

或者为Tiny Core构建一个

haveged

包-有一个可用的

另一个选项是安装rngtools包，并将其映射到/dev/uradom

  yum install rng-tools
  rngd -r /dev/urandom 

---

这样，我就不需要映射docker容器中的任何卷。

我发现的最优雅的解决方案是在单独的容器中运行Haveged：

$ docker run -v /dev/urandom:/dev/random ...

docker pull harbur/haveged
docker run --privileged -d harbur/haveged

检查是否有足够的可用熵：

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

---

如果从运行java应用程序的自建映像创建的docker容器（例如从tomcat:alpine创建的

）中存在此问题，并且无法访问主机（例如在托管k8s群集上），则可以将以下命令添加到docker文件中，以使用
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/uradom
并将
NativePRNGBlocking
替换为
NativePRNG
文件
$JAVA\u HOME/lib/security/JAVA.security
中的
NativePRNG。我没有检查这是否也适用于非基于alpine的openjdk映像，但是如果
sed
命令失败，只需检查容器中文件
java.security
的位置，并相应地调整路径即可

注意：在jdk11中，路径已更改为
$JAVA\u HOME/conf/security/JAVA.security
openssl用户
Uradom
。你在做什么需要更多？一些Java加密提供程序依赖于/dev/random（例如，用于安全的随机数生成）。我同意你不能总是控制它。在任何情况下，这里都有一些关于java
SecureRandom
vs
/dev/[u]random
——在开发机器上使用/dev/urandom而不是/dev/random对安全性的影响应该是非常有限的。“事实：/dev/urandom是类UNIX系统上加密随机性的首选来源。”关于跨平台兼容性，例如，对于那些运行Windows的可怜虫，我已经尝试了很多
rng工具
/
haved
建议，这是唯一有效的建议。谢谢@Claudiu docker toolbox for Windows仍在linux上运行，而docker for Windows 10+则在linux子系统上运行（如果我理解正确的话），因此应该仍然可以运行？这给了我以下消息：
无法调整写入唤醒阈值：只读文件系统
在docker主机上运行它，不在容器中。太基本此技术不适用于openjdk11，因为java.security文件不存在。@阿基米德斯特拉亚诺：我使用
openjdk
from（目前我自己使用Java8，但今天用于Jdk11的实验）。从这个站点下载并提取Jdk11后，我运行命令
$grep-rsecurerandom*
，它给了我路径
conf/security/java.security
（Jdk主目录下的相对路径）。我希望这会有所帮助。我是专门谈论docker hub的
openjdk:11 slim
图像，但希望它与您处于同一位置said@ArchimedesTrajano：以防万一：输入一个
openjdk:11 slim
-容器，如下所示：
$docker run--rm-it openjdk:11 slim bash
，然后
$cd/
（只是为了确保您在根目录中），然后
$grep-r securerandom*
在这里给出：
etc/java-11-openjdk/security/java.security
（搜索需要一段时间，但是