我发现运行的容器内的随机数生成存在一些问题
在 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 https://github.com/kubernetes/kubernetes/issues/60751）。是
这是最好/最简单的方法吗？
我在 google、stackoverflow 和 in 中找不到答案
kubernetes github 问题。我在 kubernetes-users slack 中也没有得到任何回复
频道，所以我希望这里有人能对此有所了解。
正确的伪随机数生成是所有加密操作的基础，
所以任何 kubernetes 用户都应该对答案感兴趣。
提前致谢。
计算机中的“随机性”有两种类型：
- 伪随机数是算法性的，如果您知道算法和起始值，则可以 100% 重现
- 真正的随机数，不存在算法并且永远无法复制。
两者各有优点。通常您希望能够重现随机数，例如在数据科学和一般科学领域。然而，对于密码学来说，可重复性从来都不是一件好事......
由于这个原因有/dev/random and /dev/urandom这些是内核提供的接口，它们从真实的硬件和用户中断和操作中获得真正的随机性——甚至是驱动程序/硬件级别的噪声等。/dev/random是一个阻塞接口，这意味着它实际上会等到熵被收集并可以返回（这可能非常慢，对于大多数应用程序来说基本上无法使用！），/dev/urandom是非阻塞的，并且总是返回“尽力而为”，为了速度而牺牲质量（但以聪明的方式，请继续阅读）。
这回答了您的部分问题：是的，在一个物理硬件上运行的所有作业的熵是密切相关的！它具有相同的来源，甚至是相同的（详细信息可能取决于操作系统设置）。这不是问题，因为如果熵足够的话，实际的随机数将完全不相关。
这让我们想到了您问题的另一个方面：在始终运行数百个线程、每秒处理数千个用户请求的服务器计算机上，每次的熵总是非常高。可用的 1000 个熵位并不是那么少。如果使用得当，就足够了，请参见下文（但我不太确定应该关注哪个级别！）。请记住：熵位池一直在不断地填充。
另一个细节/dev/urandom：在现代Linux中，这实际上是生成的伪随机数。因此，它通过算法生成数字，速度非常快但可重复。道路/dev/urandom可用于密码学的原因在于它会以随机方式定期重新播种/dev/random。这使得它非常适合所有加密需求。
因此，你不应该从中汲取/dev/random。虽然随机性的质量非常出色，但生成熵的成本却太高。你应该使用/dev/urandom并且永远保持高性能。如果您想小心谨慎，请确保entropy_avail不会下降（不确定合理的阈值是多少！不确定这是否众所周知。）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
