这只是我在家里做的一个宠物项目，因为我大部分时间都把自己锁在室内。话虽如此，我还是想把它和所有的铃声和口哨声放在一起，主要是为了学习一些新东西。早在2015年，我就实现了它的第1版，现在它已经在我的raspberryPi上像冠军一样运行了5年多。
对于更新后的版本(Angular 9/.net core 3.1(，我考虑使用Auth0作为我的身份验证提供者(但我也考虑使用AWS Cognito(。我已经确定了应用程序的微服务边界，并将尽可能使用RabbitMQ进行服务间消息传递。然而，在许多情况下，一个MS需要从另一个MS获得数据才能完成请求。从本质上讲，在一个整体中应该是DB连接的东西。我在周末读了一些关于这方面的文章，发现你可以在前端、API网关中，或者让MS A对MS B执行REST查询来进行连接。第一个感觉有点傻，因为浏览器必须执行多个请求，第二个需要我建立一个网关(我只是计划使用NGINX作为反向代理(。所以我选择了第三种选择。。。从MS A到MS B的REST请求。
我的问题。。。
在进行服务间通信时，您如何处理安全问题？我考虑过的选项，按照方便的顺序：
- 请求时将Auth头从MS A转发到MS B
- 托管MS B的内部实例，该实例不通过反向代理暴露在互联网上，只暴露跨微服务通信所需的功能。(不确定这种解释是否合理(
- 让MS A从身份验证提供者(Auth0、AWS Cognito等(请求它自己的令牌，并使用该令牌调用MS B
有标准的方法吗？
这些都是很好的问题，但不幸的是，没有一种"标准"的方法。我想说你的选择将在1到2之间，每种选择的原因如下：
选项1-发出请求时将Auth头从MS A转发到MS B
如果你要大规模应用这种做法，让多个不同的团队各自拥有不同的服务，这将是最好的途径。MS B的创建者不一定知道谁在长期给他们打电话，因此为了确保他们不会带来安全风险，暴露其服务的最简单方法是要求提供可验证的JWT。这将防止有人意外地不适当地使用他们的服务。
选项2-托管MS B的内部实例，该实例不会通过反向代理暴露在互联网上，只暴露跨微服务通信所需的功能
您可以认为这种方法有点像网关上的TLS终止。您可以在每个服务中终止TLS(如JWT的选项1(，也可以在网关处终止TLS，以确保来自外部世界的流量在进入之前得到加密，同时允许其在墙内自由流动。网关也可以是唯一负责验证和解码JWT的一方，然后在检查通过后允许流量在内部自由流动。
对于由单个团队或开发人员维护的应用程序来说，此选项非常实用，因为它非常易于编排。如果每个"内部"服务只响应一个用户ID/主题来满足请求，并且相信用户ID是从经过验证的JWT中提取的，那么您可以更容易地构建其他内部系统。此解决方案最容易上手，但如果您不能信任应用程序或团队中的其他服务或开发人员，则可能会很棘手。
选项3-让MS A从身份验证提供商(Auth0、AWS Cognito等(请求其自己的令牌，并使用该令牌调用MS B
我不建议为每个服务颁发它自己的oauth令牌。像Auth0这样的oauth提供者的JWT是发给用户的，而不是机器。
话虽如此，云安全的一个重要补充是对所有服务之间的流量进行认证和白名单。这可能是由Cilium等工具强制执行的Kubernetes NetworkPolicy，也可能是唯一的SSL证书，旨在为堆栈中的每个服务之间的关系唯一地代理通信。这种额外的安全性实际上与您的上述问题没有任何关系，但在考虑在云环境中保护进程间通信时，这将是一种额外的思考。