如何改进 kubernetes 集群容器中的随机数生成？

Question

我看到在 kubernetes 集群中运行的容器内生成随机数的一些问题（重复值）。可能是容器内缺乏熵，或者可能是其他原因，在更高的层次上，但我想研究熵角，但我有几个问题无法找到答案。

• 跨容器和节点的 /proc/sys/kernel/random/entropy_avail 的值在 950 到 1050 之间 - 这是否足够好？rngtest -c 10000 </dev/urandom返回相当不错的结果 - FIPS 140-2 成功：9987，FIPS 140-2 失败：13，但针对 /dev/random 运行它只是永远挂起。

• 容器中的 entropy_avail 值似乎遵循节点上的值。如果我cat /dev/random >/dev/null在节点上执行，entropy_avail 也会在该节点上运行的容器内下降，即使docker inspect不表明 /dev/*random 设备是从节点绑定安装的。那么它们是如何关联的呢？一个容器可以消耗该节点上其他容器可用的熵吗？

• 如果 entropy_avail 在 1000 左右是值得关注的，那么增加该值的最佳方法是什么？似乎部署haveged守护进程是一种方式（https://github.com/kubernetes/kubernetes/issues/60751）。这是最好/最简单的方法吗？

我在 google、stackoverflow 和 kubernetes github 问题中找不到答案。我在 kubernetes-users slack 频道中也没有得到任何回应，所以我希望这里有人可以对此有所了解。

正确的伪随机数生成是所有加密操作的基础，因此任何 kubernetes 用户都应该对答案感兴趣。

提前致谢。

Answer 1

计算机中的“随机性”有两种类型：

1. 伪随机数是算法性的，如果您知道算法和起始值，则可以 100% 重现
2. 真正的随机数，不存在算法并且永远无法复制。

两者各有优点。通常，您希望能够重现随机数，例如在数据科学和一般科学中。然而，对于密码学来说，可重复性从来都不是一件好事......

因此，内核提供了/dev/random一些/dev/urandom接口，这些接口从真实的硬件和用户中断和操作中获得真正的随机性——甚至是驱动程序/硬件级别的噪声等。While/dev/random是一个阻塞接口，意味着它实际上会等到熵被收集。并且可以返回（这可能非常慢，对于大多数应用程序来说基本上无法使用！），/dev/urandom是非阻塞的并且总是返回“尽力而为”，牺牲质量以换取速度（但以聪明的方式，请继续阅读）。

这回答了您的部分问题：是的，在一个物理硬件上运行的所有作业的熵是密切相关的！它具有相同的来源，甚至是相同的（详细信息可能取决于操作系统设置）。这不是问题，因为如果熵足够的话，实际的随机数将完全不相关。

这让我们想到了您问题的另一个方面：在始终运行数百个线程、每秒处理数千个用户请求的服务器计算机上，每次的熵总是非常高。可用的 1000 个熵位并不是那么少。如果使用得当，就足够了，请参见下文（但我不太确定应该关注哪个级别！）。请记住：熵位池一直在不断地填充。

另一个细节/dev/urandom：在现代Linux中，这实际上是生成的伪随机数。因此，它通过算法生成数字，速度非常快但可重复。可用于密码学的方法/dev/urandom是，它以随机方式定期重新播种/dev/random。这使得它非常适合所有加密需求。

因此，您不应该从/dev/random. 虽然随机性的质量非常好，但生成熵的成本太高。您应该使用/dev/urandom并且始终保持高性能。如果你想小心，请确保entropy_avail不会下降（不确定合理的阈值是多少！不确定这是否是众所周知的。）