假设我在kubernetes中有几个服务。我有一个集群的入口点，它是一个面向公众的服务，旨在验证JWT令牌(来自AWS cognito(。
入口点将请求路由到内部服务，而内部服务通常会向其他内部服务发出更多请求。
我的问题是：只验证JWT一次并在没有任何形式的身份验证的情况下进行其他通信，只传递用户id(或任何其他所需的数据(就足够了吗？还是在服务之间进行http请求时需要某种形式的身份验证？如果是，哪个？我应该再次验证JWT吗？我应该有服务器证书或类似的东西吗？
发布了一个社区wiki答案以提高可见性。请随意扩展。
正如David Szalai的评论所提到的，这取决于您的安全和项目要求：
如果在k8s中使用零信任模型，则可以在服务之间使用带有服务网格的mTLS。如果您需要将用户身份验证信息传播到不同的服务，那么传递JWT也是很好的。
在当前(项目(中，我们将使用带有服务网格的mTLS，并在接收方需要用户信息的地方发送JWT和请求，并在那里再次解析/验证它。
如果你的应用程序没有内置的身份验证/授权机制，你可以尝试Istio-查看以下文章：
- Istio文档-安全
- Istio&JWT：微服务身份验证分步指南
还可以查看这些关于Kubernetes:中身份验证的文章
- Kubernetes文档-身份验证
- 使用Kubernetes身份在微服务之间进行身份验证
编辑：
为什么
在安全方面，我们说：
安全中的一个常见原则是，给定系统的强度只与最薄弱环节的强度一样强。
本文-服务网格时代：使用Istio保护您的环境提到了一些可能在不安全系统中进行的攻击，如中间人攻击和重放攻击：
降低这种风险的一种方法是确保对等端仅使用不可移植的身份进行身份验证。双向TLS身份验证(mTLS(确保对等身份绑定到TLS通道，并且不能重播。它还确保所有通信在传输过程中都是加密的，并降低了中间人攻击和目的地服务重播攻击的风险。虽然双向TLS有助于强烈识别网络对等方，但最终用户身份(或来源身份(仍然可以使用JWT等承载令牌进行传播。
鉴于生产网络中威胁的激增和特权访问点的增加，越来越有必要对微服务架构采用零信任网络安全方法。这种方法要求所有访问都经过强身份验证、基于上下文授权、记录和监控……并且必须针对动态生产环境优化控制。
在不添加额外安全层(如集群中的mTLS和服务网格(的情况下，我们假设集群中的微服务之间的通信是在完全可信的网络中完成的，因此它们可以让攻击者有可能通过网络利用业务资产：
如今，许多微服务部署主要担心边缘安全，通过API暴露微服务，并在边缘使用API网关保护微服务。一旦请求通过API网关，微服务之间的通信就假设是一个可信的网络，并向攻击者暴露无限的可能性，使其能够访问网络，利用微服务暴露的所有有价值的商业资产。