我发现在kubernetes集群中运行的容器内生成随机数存在一些问题（重复值），可能是容器内缺乏熵，也可能是更高层次上的其他问题，但我想从熵的Angular 进行研究，我有几个问题很难找到答案。
- /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/* 随机设备是从节点绑定挂载的。那么它们是如何关联的呢？一个容器是否可以消耗该节点上其他容器可用的熵？ - 如果entropy_avail大约为1000，那么增加该值的最佳方法是什么？部署
haveged守护进程似乎是一种方法（https://github.com/kubernetes/kubernetes/issues/60751），这是最佳/最简单的方法吗？
我在google、stackoverflow和kubernetes github issues上找不到答案，在kubernetes-users slack频道上也没有得到回复，所以我希望这里有人能给我一些启示。
正确的伪随机数生成是所有加密操作的基础，因此任何kubernetes用户都应该对答案感兴趣。
先谢了。
1条答案
按热度按时间rkttyhzu1#
计算机中有两种类型的“随机性”：
1.伪随机数是算法的，如果你知道算法和起始值，可以100%重现，以及
1.真正的随机数，其中不存在算法并且永远不能被复制。
两者都有优点。通常你希望能够重现随机数，例如在数据科学和一般科学中。然而，对于密码学来说，重现性从来都不是一件好事。
由于这个原因，存在
/dev/random和/dev/urandom，它们是内核提供的接口，从真实的硬件和用户中断和动作中获得真正的随机性--甚至是驱动程序/硬件级别上的噪声等。而/dev/random是阻塞接口，这意味着它实际上等待熵被收集并且可以被返回（这可能非常慢，基本上不能用于大多数应用程序！），/dev/urandom是无阻塞的，总是返回“尽最大努力”，为了速度而牺牲质量（但以一种聪明的方式，请继续阅读）。这回答了您的部分问题：是的，在一个物理硬件上运行的所有作业的熵是强相关的！它具有相同的来源，甚至是相同的（具体情况可能取决于操作系统设置）。这不是问题，因为如果熵足够大，实际的随机数将完全不相关。
这就引出了你问题的另一个方面：在服务器机器上，有数百个线程一直在运行，每秒处理数千个用户请求，每次的熵总是很高。2 1000个可用的熵比特不是那么少。3如果使用得当，这就足够了，见下文（但我不太确定应该关注哪个级别！4）。5记住：熵比特池一直连续地填充。
关于
/dev/urandom的另一个细节：在现代Linux中，这实际上是伪随机数生成。因此，它通过一种算法生成数字，非常快但可重复。/dev/urandom可用于加密的方式是，它以随机方式从/dev/random周期性地重新播种。这使它完全适合所有加密需求。因此，你不应该从
/dev/random中提取。虽然随机性的质量会很好，但生成熵的成本太高。你应该使用/dev/urandom，它总是很有性能。如果你想小心，请确保entropy_avail不会下降（不确定什么是合理的阈值！不确定这是否是众所周知的）。