微服务架构中 docker 容器之间的身份验证，绕过 JWT 身份验证进行内部调用

Question

我有以下 docker 架构，使用 docker compose 进行编排：

• Service1：前端应用，react 应用
• Service2：ExpressJS 服务器
• Service3：Django 服务器

三个应用程序通过 HTTP API 调用相互通信。谁可以呼叫谁没有限制。每个应用程序都对外暴露

用户在前端应用程序 (Service1) 上进行身份验证，并解析一个 JWT，该 JWT 可以在以后传递给每个其他后续调用，然后每个其他服务都有一个身份验证层来验证 JWT 调用。

我的问题是：我们如何在没有任何用户活动（没有 JWT）的情况下验证从 Service2 到 Service3 的调用？

这是 crons 或维护作业所必需的。

我的第一个解决方案是在 docker-compose 中创建一个具有固定子网的 docker 网络，如下所示：

networks:
  our-network:
    ipam:
      driver: default
      config:
        - subnet: "172.100.100.0/24"

然后，在 Service2 和 Service3 中，我允许来自该子网的 API 调用未经身份验证。 我担心这可能是一个安全问题，想知道是否有更好的解决方案。

Answer 1

JWT 令牌通常使用属于令牌颁发者的 私钥签名。将 JWT 令牌作为 issuer claim 是一种很好的做法。

通常可以通过两种方式验证 JWT 令牌：

• 调用发行人的OAuth token introspection endpoint - 但这会增加更多延迟
• 使用来自发行者的缓存公钥进行本地验证 - 难以添加注销功能

如果您使用缓存解决方案，这不会增加太多延迟，JWT 颁发者必须实现一个OpenID Discovery endpoint，包括对JWKS endpoint 的引用，其中颁发者发布其公钥。

如果您使用 Kubernetes，您可以使用带有 OpenPolicyAgent 的 sidecar，为应用程序执行令牌验证。开发人员在每个应用程序中实现令牌验证功能并不是那么有趣，所以这是一个有趣的替代方案。您还可以使用此解决方案轻松添加授权规则。

我们如何在没有任何用户活动（没有 JWT）的情况下验证从 Service2 到 Service3 的调用？

当 Service2 收到用户的请求并通过 JWT 进行身份验证时 - 它代表用户向 Service3 发出请求，因此它也应该将 JWT 令牌传递给 Service3 - 这样 Service3 才能运行并只使用属于用户的资源，例如从数据库中获取。这可以在没有用户干预的情况下完成（直到 JWT 过期）。

这是 crons 或维护作业所必需的

对于代表用户执行的作业，通常需要存储具有较长过期时间的 JWT 令牌，例如在数据库中。通常这可以由用户撤销，并且通常在 3 个月左右后过期，然后用户可能需要再次进行身份验证（或超过 3 个月 - 取决于您的需要）。重要的是，此类令牌具有较低的权限，通常只有作业所需的权限。