如果外部无法直接访问api,为什么内部服务之间的通信需要像oauth这样的授权?

u84*_*six 3 authentication server-to-server docker kubernetes microservices

这只是关于微服务架构的一般问题。如果外部世界无法访问它们,为什么 2 个或更多内部服务仍然需要像 oauth2 这样的令牌身份验证来相互通信?他们的 api 不能只是过滤内部 IP 地址吗?这种方法有什么风险?

Jon*_*nas 6

如果外部世界无法访问它们,为什么 2 个或更多内部服务仍然需要像 oauth2 这样的令牌身份验证来相互通信?

不需要OAuth2 或令牌身份验证,但您应该使用它。这取决于您流量的信任程度。现在在“云时代”,不拥有自己的数据中心是很常见的,因此还有另一部分拥有您的服务器和网络硬件。该部分可能会配置错误,例如来自另一个客户的流量被路由到您的服务器。或者,您可能设置了自己的基础架构并进行了错误配置,从而导致来自测试环境的流量无意中路由到您的生产服务。Google BeyondCorpZero Trust Networks 中描述了处理这种新情况的新做法。

本质上,您不应该信任网络流量。对所有请求使用身份验证(例如 OAuth2、OpenID Connect、JWT),并使用 TLS 或 mTLS 加密所有流量。

他们的 api 不能只是过滤内部 IP 地址吗?这种方法有什么风险?

见上文,也许你也不应该相信内部流量。

此外,现在您的最终用户通常使用OpenID Connect(基于 OAuth2 的身份验证)进行身份验证 - 在Authorization: Bearer标头中发送 JWT 令牌。在处理请求时,您的大部分系统都将在用户上下文中运行,该上下文位于 JWT 令牌中,并且很容易将该令牌在请求中传递给用户请求的操作中涉及的所有服务。


Arg*_*dhu 2

您可以使用 Oauth 在微服务公开的 api 上实现非常精细的基于角色的访问控制 (RBAC),而使用过滤 IP 地址则无法做到这一点。