Kubernetes 上微服务间身份验证的最佳实践？答案

【问题标题】：Best practices for inter-microservice authentication on Kubernetes?Kubernetes 上微服务间身份验证的最佳实践？
【发布时间】：2020-11-27 22:59:20
【问题描述】：

我正在编写一个要部署在 Kubernetes 上的服务。客户端将是其他服务，而不是人，这些服务可能位于其他命名空间甚至集群中。我的目标是：

我知道 Kubernetes 不提供真正帮助解决这些问题的服务，我需要在我的服务中构建一些明确的内容。我想了解当前的最佳实践是什么，以及如何最大限度地利用 Kubernetes 或生态系统中的可用功能，以实现这些目标，同时最大限度地减少编码和管理负担。我考虑过的几个选项：

自定义用户名/共享密码。我可以将共享密钥传递给所有调用服务，然后编写我自己的自定义代码来验证共享密钥是否匹配。我认为将这些作为不记名令牌传递是正确的举动。使用 Kubernetes 服务帐户和角色对象是否是这些共享机密的合理容器？如果是这样，是否有使查找、关联和策略工作更容易的库？
智威汤逊。 JWT 似乎更倾向于传递声明，例如最终用户身份，并且似乎要求所有参与组件共享相同的 JWT 机密。由于我不希望 call-service-foo 能够作为 call-service-bar 进行身份验证，因此尚不清楚 JWT 是否正确。想法？
mTLS。我可以为所有参与的服务颁发 TLS 证书。我可以使用哪些组件来自动颁发这些证书？我应该尝试使用 Kubernetes 服务帐户或角色对象来管理这些，还是滚动我自己的 CRD？
Istio。看起来 Istio 可以透明地做很多这样的事情，但到目前为止，我发现的所有解释这一点的资源似乎都假设透明性是一个目标。但是，由于我需要调用服务的身份，是否可以从 Istio 中获取？如果我的调用者不在我的集群中，这可以工作吗？
SPIRE (spiffe.io)。这看起来很适合我的用例，但它似乎是新的，我不知道人们对它有多少经验。

这些选项中的任何一个（并请纠正我对其中任何一个的理解）是否作为最佳做法脱颖而出，还是我应该考虑其他选项？

谢谢！

【问题讨论】：

【解决方案1】：

我知道我现在迟到了，但如果其他人在看： Istio 已包含多集群支持，它使通信变得轻松。

【讨论】：

【解决方案2】：

您需要一个充当微服务 API 端点网关的组件。这种组件属于一种叫做“API 管理”（Wikipedia page）的软件类别，它的使用不仅限于 Kubernetes。

有许多 API 管理软件可供选择，例如 Wikipedia 页面中列出的，但我的项目使用 Gravitee，到目前为止，由于其简单的管理 UI，我们很喜欢它。随意探索它https://gravitee.io/。

注意除了作为用户之一之外，我与 Gravitee.io 没有任何关系（尽管我确实为一个 PR 做出了贡献）

【讨论】：