[发明专利]基于Kubernetes的认证授权方法及系统

说明书

本公开的实施例提供了基于Kubernetes的认证授权方法、系统、设备和计算机可读存储介质。所述方法包括API网关接收客户端发送的服务调用请求，将所述服务调用请求转发至认证授权模块；所述认证授权模块接收所述服务调用请求，验证Access Token；如果认证成功，根据预设策略对所述服务调用请求进行访问控制；如果所述服务调用请求被预设策略允许，则向所述API网关发送授权指示；所述API网关接收所述授权指示，将所述服务调用请求转发至对应的后端微服务。提供了一种零侵入、零成本的方法，减轻了业务服务开发人员的开发成本；通过授权规则服务、域名双维度配置，可以对页面针对不同的域名设置不同的权限，从而最大限度的保护业务的安全。

技术领域

本公开的实施例一般涉及云计算技术领域，并且更具体地，涉及基于Kubernetes的认证授权方法、系统、设备和计算机可读存储介质。

背景技术

传统的开发中，由于所有的功能模块都集中在一个单体应用中，因此，只用在这个单体应用中编写相应的用户授权验证功能即可满足大部分的需求。但是随着微服务化的趋势，许多传统的单体服务都被拆分成微服务的形式，即多个轻量的微服务共同实现原来一个单体应用的功能。这样就会面临以下问题：

1. 由于每个微服务都需要进行权限的验证，因此，不可避免的需要在每个微服务里都要编写大量且相同的授权验证的代码。而且这种逻辑是牵一发动全身的，一旦授权验证的逻辑发生变化，所有的微服务都要进行相应的修改来进行适配；

2. 对于微服务来说，微服务具体的功能才是开发人员应关注的部分，而授权验证的加入，让开发人员过多的关注了核心功能以外的部分，从而降低了代码的开发效率；

3. 由于是多个微服务功能实现原来一个单体应用的功能，每个微服务又可能具有多个实例，因此，开发人员不得不作一些额外的工作来维持各个微服务各个实例的登录状态。例如，系统A由商品服务、订单服务、购物车服务等多个微服务组成，如果用户登录了系统A的商品服务，那么订单服务、购物车服务等服务应该也是登录状态。另外，即使对于多个传统单体应用，我们也会需要各个单体应用共用同一套账号密码体系，从而实现单点登录的功能（例如，用户如果在系统A登录，如果用户打开系统B，也应该是登录状态）。

为了解决上述问题，业内采用Spring Cloud Gateway在网关层面解决统一认证授权的问题。Spring Cloud Gateway 是开源框架Spring Cloud的一个子项目，在整个SpringCloud框架中，Spring Cloud Gateway可以起到流量入口的作用。由于Spring CloudGateway起到了流量入口的作用，因此，开发人员在Spring Cloud Gateway这一层通过自行编码来定制各种各样的过滤策略来对流量进行过滤，例如，拦截恶意流量，对恶意访问进行限流，将来源不用的流量转授权认证发到不同的请求。即针对上述问题1-3，通过在网关层面自行编码来定制认证授权策略来解决前面提出的问题。虽然Spring Cloud Gateway可以在网关层面解决统一认证授权的问题，但是也存在诸多的缺点：

1. Spring Cloud Gateway是Spring Cloud的一个子项目，因此，用户如果想要使用Spring Cloud Gateway，就必须使用Spring Cloud，而Spring Cloud是Kubernetes出来前的产物，其大部分功能已经被Kubernetes所替代；

2. Spring Cloud是对代码有侵入性，即微服务的代码要引入Spring Cloud的依赖，以及在代码中进行相应的开发，才能使用Spring Cloud提供的各种特性；

3. Spring Cloud学习成本较大，需要每个开发人员都要对Spring Cloud相当的熟练才可以更好的使用Spring Cloud；