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

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

验证呼叫服务

授权呼叫服务

根据呼叫服务的标识应用某些策略（如配额）

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

• 自定义用户名/共享机密。我可以将共享机密传递给所有调用服务，然后编写自己的自定义代码来验证共享机密是否匹配。我认为将这些作为不记名代币传递是正确的做法。使用Kubernetes serviceaccount和role对象是否是这些共享机密的合理容器？如果是这样，是否有使查找、关联和策略工作更容易的库

• JWT。JWT似乎更倾向于传递声明，如最终用户身份，并且似乎要求所有参与组件共享相同的JWT机密。因为我不希望调用服务foo能够作为调用服务条进行身份验证，所以不清楚JWT是否正确。想法

• mTLS。我可以为所有参与服务颁发TLS证书。我是否可以使用一些组件来自动颁发这些证书？我是否应该尝试使用Kubernetes serviceaccount或角色对象来管理这些，或者使用我自己的CRD

• Istio。看起来Istio可以透明地做很多事情，但到目前为止，我找到的所有解释这一点的资源似乎都假设透明是一个目标。但是，由于我需要呼叫服务的身份，有可能从Istio中获取吗？如果我的呼叫者不在我的群集中，这能工作吗

• 尖顶（spiffe.io）。这看起来很适合我的用例，但它似乎是新的，我不知道人们对它有多少经验

这些选项（请纠正我对其中任何选项的理解）是否作为最佳实践脱颖而出，或者我是否应该考虑其他选项

---

谢谢大家!

您需要的是一个组件，它充当微服务API端点的网关。这种组件属于一种称为“API管理”（API management）的软件，其使用不仅限于Kubernetes

有很多API管理软件可供选择，如维基百科页面中列出的，但我的项目使用Gravitee，到目前为止，由于其简单的管理UI，我们非常喜欢它。请随时浏览

注意：除了作为用户之一之外，我与Gravitee.io没有任何关系（尽管我曾参与过一次公关活动）