微服务集群中的授权架构

Question

我有一个带有微服务架构的项目（在 Docker 和 Kubernetes 上），两个主要的应用程序是使用 AIOHTTP 和 Django 用 Python 编写的（还有 Ingress 代理、静态文件服务器，还有几个是用 NginX 制作的）。我想将这些 Python 应用程序拆分为单独的更小的微服务，但为了实现这一点，我可能还应该将身份验证移到单独的应用程序中。但是我该怎么做呢？

也许我还应该补充一点，我问的不是特定的身份验证方法，如 OAuth、JWT 等，而是集群架构内的依赖关系和职责划分。

在我看来，一个不错的解决方案是 Ingress NginX 代理服务器的一些插件，或者之前的微服务，这样我的 Python 身份验证代理就不会关心方法的目的地，就像一些中间件一样，只需读取 headers/cookies，检查访问令牌或sessionId，如果访问有效则设置userId，并进一步传递请求。

一个简短的简化架构如下所示：

这就是我的想象，提及更少的复杂连接：

但我不确定这是否合理。此外，这种方法会降低 K8s Ingress 的优势，它为从 bash 更新路径表提供了惊人的接口，但是据我所知，它不允许在它之前运行任何请求处理程序，所以我必须在没有很好的 K8s 集成的情况下运行自定义 NginX 代理。

那么，还有哪些其他可能的架构解决方案？

我只能想象创建一个请求处理程序，它执行所有授权并将请求传递给其他不关心身份验证的微服务（或通过 RPC），但我认为这通常不是完美的解决方案。

Answer 1

理论

嗯，我在网上挖掘和咨询了一年半之后，找到了很多信息。有一个名为 API Gateway 的架构模式，它描述了集群中的入口点，这正是 Kubernetes Ingress 所做的，也是我在问题中所想象的。在一般情况下，它是代理服务器，它是集群微服务的唯一入口点，它可以执行缓存、DDoS 保护，它可以支持不同的 API 协议、操作 URI、管理 API 节流、货币化和执行身份验证我需要。因此，在集群内部的微服务通信过程中没有身份验证，因为所有需要的参数，标识符都会在请求中呈现。

实施

在 Kubernetes 中，NginX Ingress 相当流行，它还支持 Basic Auth 和 OAuth2，这不是一个完美的解决方案，但至少是一些东西。 Kubernetes 有其他 Ingress 解决方案：Kong、Ambassador、Traefik，它们提供了更多功能（尽管 Kong 也基于 NginX）。

在 Java 和 Spring 的世界中，Spring Cloud Gateway 的存在就是为了解决这些问题，就像 K8s Ingress 一样，它允许使用 YAML 描述路径表，但它是可扩展的，允许轻松为任何身份验证方法嵌入您的自定义代码。

此外，大多数云平台都提供了自己的API网关服务，或多或少的功能，包括Google Cloud、Red Hat、AWS、Yandex Cloud。但是，它们似乎缺乏身份验证方法，就像扩展的机会一样，尽管它们与这个问题的关系不大。

阅读

您可以在此处找到有关 API 网关模式及其实现的更多信息：

• microservices.io: API Gateway pattern
• RedHat: What does an API gateway do?
• kubernetes.github.io: NginX Ingress External OAUTH Authentication
• learnK8S.io: Kubernetes API Gateway
• cloud.spring.io: Spring Cloud Gateway

Answer 2

对于微服务，JWT 是首选的身份验证和授权方式。 您可以使用GCP IAM 或OKTA 等云资源。或者，您可以在集群中将 Keycloak 作为微服务运行。

1. 用户是在这些资源之一中创建的。
2. 一旦用户通过身份验证，就会返回一个 JWT 令牌（到 前端）。
3. 令牌包含身份验证和授权相关信息 用户。
4. 此令牌再次从前端发送到每个后端服务 请求。
5. 后端服务将检查身份验证和授权并 做出相应的回应。

此外，令牌通常在固定的时间内有效。所以前端应用应该定期刷新令牌。