微服务集群中的授权架构

时间：2020-11-04 21:08:49

标签： python authentication kubernetes proxy architecture

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

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

在我看来，一个不错的解决方案是在Ingress NginX代理服务器上安装一些插件，或者在它之前使用微服务，这样我的Python身份验证代理就不会在意方法的目的地，例如某些中间件，只读取标头/ Cookie，检查访问令牌或sessionId，然后设置userId（如果访问有效），然后进一步传递请求。

下面简要介绍了一个简化的体系结构：

Current Architecture

这就是我想像的，提到的复杂连接较少：

Desired Architecture

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

因此，还有哪些其他可能的体系结构解决方案？

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

2 个答案:

答案 0 :(得分：0)

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

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

令牌通常在固定的时间内有效。因此前端应用程序应定期刷新令牌。

答案 1 :(得分：0)

理论

好吧，在互联网上进行了一半半的咨询后，我发现了很多信息。有一个名为 API网关的体系结构模式，它描述了集群中的入口点，而这正是 Kubernetes Ingress 的作用，也是我在问题中所想象的。通常，它是代理服务器，它是集群微服务的唯一入口点，它可以执行缓存，DDoS保护，可以支持不同的API协议，操纵URI，管理API限制，获利和执行身份验证。我需要。因此，在集群内部的微服务通信期间不会进行身份验证，因为所有必需的参数，标识符将在请求中显示。

实施

在Kubernetes中， NginX Ingress 非常流行，它还支持Basic Auth和OAuth2，虽然这不是一个完美的解决方案，但还是值得借鉴的。 Kubernetes还有其他Ingress解决方案： Kong，大使，Traefik ，它提供了更多功能（尽管Kong也基于NginX）。

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

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

阅读

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

相关问题
最新问题