58

在虚拟化 Linux 系统中耗尽熵似乎是一个常见问题（例如/dev/random 非常慢？，让 linux 缓冲 /dev/random）。尽管使用了硬件随机数生成器 (HRNG)，但通常建议使用像HAVEGED这样的熵收集守护进程。但是熵收集守护进程 (EGD) 不能在 Docker 容器内运行，它必须由主机提供。

对于基于 Ubuntu、RHEL 等 Linux 发行版的 docker 主机，使用 EGD 效果很好。让这样的守护进程在基于 Tiny Core Linux (TCL) 的 boot2docker 中工作似乎是另一回事。虽然 TCL 有扩展机制，但熵收集守护进程的扩展似乎不可用。

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

由于在 boot2docker 中运行 EGD 似乎太难了，所以我想简单地使用 /dev/urandom 而不是 /dev/random。使用 /dev/urandom 的安全性稍差一些，但对于大多数不生成长期加密密钥的应用程序来说仍然可以。至少在 boot2docker 中进行开发/测试应该没问题。

4

6 回答 6

58

我刚刚意识到，将 /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

至少我现在知道如何构建自己的 boot2docker 映像了 ;-)

于 2014-09-24T18:57:17.043 回答
16

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

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

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

$ cat /proc/sys/kernel/random/entropy_avail
2066
于 2015-12-21T12:58:03.827 回答
6

另一种选择是安装rng-tools包并将其映射到使用 /dev/urandom

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

有了这个，我不需要在 docker 容器中映射任何卷。

于 2015-12-18T18:48:26.087 回答
3

由于我不喜欢修改我的 Docker 容器以进行开发/测试，因此我尝试修改 boot2docker 映像。幸运的是，boot2docker 镜像是使用 Docker 构建的，可以轻松扩展。所以我建立了自己的 Docker build boot2docker-urandom。它使用此处找到的 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 ，而是使用相应的内核设备 - 仍然阻塞。

于 2014-09-24T15:45:15.660 回答
2

Alpine Linux可能是轻量级docker主机的更好选择。高山LXC和docker图像只有 5mb（相对于 27mb boot2docker）

我haveged在Alpine上为LXC客人使用，在 Debian 上为docker客人使用。它提供了足够的熵来在容器中生成gpg/ssh密钥和openssl证书。Alpine 现在有一个官方docker回购。

或者haveged为 Tiny Core 构建一个包 - 有一个可用的包构建系统。

于 2015-05-18T00:31:42.733 回答
2

如果您在从运行 java 应用程序（例如 created ）的自建映像创建的 docker 容器中遇到此问题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/randombyfile:/dev/urandom和NativePRNGBlockingby ，这导致 tomcat 在 vm 上以相当快的速度启动。我还没有检查这是否也适用于非基于 alpine 的 openjdk 图像，但如果命令失败，只需检查容器内文件的位置并相应地调整路径。NativePRNG$JAVA_HOME/lib/security/java.securitysedjava.security

注意：在 jdk11 中路径已更改为$JAVA_HOME/conf/security/java.security

于 2018-10-19T08:58:12.300 回答