使用相同密钥的部署之间的 K8S 同步答案

【问题标题】：K8S synchronization between deployments which use the same secret使用相同密钥的部署之间的 K8S 同步
【发布时间】：2020-03-17 00:02:20
【问题描述】：

在我的 k8s 集群中，我有两个部署：一个用于使用给定的密钥对生成 JWT，另一个用于使用相同的密钥对验证 JWT。
两个部署都使用相同的 k8s 密钥，其中包含密钥/对。
当我想撤销/更新该密钥对时，如何在部署之间创建一致性？实际上，我希望所有生成的 JWT 都将得到验证，尽管有两个不同的微服务，并且不一定会同时更新两个微服务的所有 pod 以使用新密钥。
如何防止此类验证失败的误报？

【问题讨论】：

为什么不对两者使用相同的秘密？
（确实需要在同一个命名空间中运行）
我实际上使用了相同的秘密。更新秘密后，我会对两个部署进行部署更新。但是来自两个部署的 pod 不同步 - 然后理论上用户可以从未更新的 pod 中获取 jwt，而不是当他去验证它时 - K8S 可能会将他的请求重定向到“新” pod（带有新秘密）-他的请求将失败。我该如何预防？
@YosiKarl 密钥轮换通常以两端（或至少接收端）同时支持两个版本一段时间的方式实现。
我同意，但是如何解决其中一个使用新密钥的 pod 生成 JWT 并且以下请求（包含 JWT）被发送到其中一个使用旧密钥的 pod？

标签： kubernetes

【解决方案1】：

这个问题不可能有一个通用的解决方案：你必须自己协调各方。

常见的解决方案是发布一个新的秘密，让所有参与者都接受。

然后在一段时间后停止发布旧版本并将其从各处删除。

【讨论】：

【解决方案2】：

在您的 Helm chart 或 Kustomize 清单中，将 secret 内容的哈希设置为 pod 模板上的注释，当 secret 的内容发生变化时将自动触发重新部署。

或者，您的软件可以检测文件中的更改并重新加载它们。

【讨论】：

这不会解决在部署推出中途发生的竞争问题。
除了设置更好的密钥轮换系统之外，没有真正的解决方案。拥有一个活动密钥和多个允许的密钥，而不是一个签名密钥。发行者仅使用活动密钥发出，但检查器将允许任何允许的密钥。因此，在更改键时，您将活动键移至允许，然后创建一个新的活动键。
“除了建立一个更好的密钥轮换系统之外，没有真正的解决方案”——这就是我的观点：你的解决方案表明从一开始就有问题。跨度>
确实（虽然它卖得像灵丹妙药）:-)