微服务集群中的授权架构 [英] 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，大使，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网关服务，包括 Google Cloud ， Red Hat ， AWS ，

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 Cloud Gateway

• 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

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