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

Question

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

Answer 1

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

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

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

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

见上文，也许您也不应该相信内部流量。

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

Answer 2

对于内部服务，通常较少涉及验证令牌（理论上这已经由面向外部的网关/api 完成），而更多地涉及传递用户的识别信息。即使是内部服务也很常见想知道请求/代理用户是谁以获得权限和访问控制，有时告诉每个需要用户范围的服务创建者接受 Authorization 标头中的 JWT 比它更容易说，“在X-COMPANY-USER-ID标题中查找用户 ID”。

Answer 3

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