微服务集群中的授权架构 [英] Authorization architecture in microservice cluster

问题描述

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

I have a project with microservice architecture (on Docker and Kubernetes), and 2 main apps are written in Python using AIOHTTP and Django (also there are and Ingress proxy, static files server, a couple more made with NginX). I'd like to split these Python apps into separate smaller microservices, but to accomplish this probably I also should move authentication in a separate app. But how can I do this?

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

Probably I should also add that I'm asking not about specific authentication methods like OAuth, JWT, etc, but about dependencies and responsibilities splitting inside cluster architecture.

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

To my mind, a nice solution would be some plugin to Ingress NginX proxy server, or a microservice before it, so that my Python authenticating proxy won't care about methods destination, like some middleware, just read headers/cookies, check access token or sessionId, then set userId if the access is valid, and pass the request further.

下面提供了一个简短的简化架构:

A brief and simplified architecture is presented below:

这是我的想象，少说复杂的连接:

And here is what I imagine, mention fewer complicated connections:

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

But I'm not sure if this is reasonable. In addition, such approach would reduce advantages of K8s Ingress, which provides amazing interface for updating path table from the bash, but, as far as I know, doesn't allow to run any request handler before it, so I'll have to run custom NginX proxy without nice K8s integration.

因此，还有哪些其他可能的架构解决方案?

Thus, what are other possible architectural solutions?

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

I could only imagine creation of a single request handler, that performs all the authorisation and passes requests to other microservices (or by RPC), which don't care about authentication, but I don't think this is a generally perfect solution.

推荐答案

理论

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

Theory

Well, I found a lot of info after digging on the Internet and one and a half of consultations. There is an architectural pattern named API Gateway, which describes an entry point in a cluster, and this is just what Kubernetes Ingress does, and what I imagined in my question. In a general case, it is proxy server, which is the only entry point to the cluster microservices, and it may perform caching, DDoS protection, it may support different API protocols, manipulate URIs, manage API throttling, monetisation, and perform the authentication I need. Therefore, there is no authentication during microservices communication inside the cluster, because all the required arguments, identifiers will be presented in the requests.

在 Kubernetes 中，NginX Ingress 非常流行，它还支持 Basic Auth 和 OAuth2，这不是一个完美的解决方案，但至少有一些.Kubernetes 有替代的 Ingress 解决方案:Kong、Ambassador、Traefik，它们提供了更多的功能(尽管 Kong 也基于 NginX).

In Kubernetes, NginX Ingress is quite popular, it also supports Basic Auth and OAuth2, which is not a perfect solution, but at leat something. There are alternative Ingress solutions for Kubernetes: Kong, Ambassador, Traefik, which provide much more features (though Kong is based on NginX too).

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

In the world of Java and Spring the Spring Cloud Gateway exists to solve ssuch problems, which, just like K8s Ingress, allows to describe path tables with YAML, yet it is extendable, allows to easily embed your custom code for any authentication method.

此外，大多数云平台都提供自己的API网关服务，或多或少的功能，包括谷歌云、红帽、AWS、Yandex 云.然而，他们似乎缺乏身份验证方法，就像扩展的机会一样，尽管它们与这个问题没有太大关系.

Besides, most of cloud platforms provide their own API gateway services with more or less features, including Google Cloud, Red Hat, AWS, Yandex Cloud. However, it seems they lack authentication methods just like opportunity to be extended, though they aren't much relevant in this question.

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

You can find more about API Gateway pattern and it's implementations here:

• microservices.io:API 网关模式
• RedHat:API 网关有什么作用做什么?
• kubernetes.github.io:NginX Ingress 外部 OAUTH身份验证
• learnK8S.io:Kubernetes API 网关
• cloud.spring.io:Spring 云网关

这篇关于微服务集群中的授权架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！