分布式和微服务架构已经越来越多的应用在企业中,服务间的身份认证和令牌管理是其必不可少的部分。我们的团队在构建一站式门户站点时,需要集成多个后端微服务,每一个服务需要访问不同的系统来完成对应的业务场景 (比如:订单系统,偏好推荐系统,产品系统等)。我们需要将这些系统有机的进行整合,通过在项目中的不断实践,配置恰当的身份认证和令牌管理,我们总结了一些微服务间的身份认证、令牌管理的架构演进与最佳实践。
背景
我们的系统是使用微服务架构开发并打包到容器中,这些系统部署在 Kubernetes(它是用于自动化部署,扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器分组为逻辑单元,以便于管理和发现)。在这些站点中,前端系统需要携带令牌访问不同服务,每一个服务需要携带令牌访问不同的下游服务来完成相应的业务场景,所以这个过程涉及到各个服务之间的身份认证和令牌管理。系统架构涉及到多个微服务,这些微服务系统由不同的团队维护,我们引进了不同的方案来解除各个系统在鉴权上的耦合,降低系统的复杂性,提高鉴权的可复用性和可维护性。本文我们将结合项目中引进的系统自身鉴权,API网关鉴权和authentication sidecar模式,介绍整个上下游服务之间的身份认证、令牌管理的架构演进与最佳实践。
系统自身鉴权
系统自身鉴权,就是每个应用系统自己进行身份认证和令牌管理,下面我们就从Inbound Authentication和Outbound Authentication来分析。Inbound Authentication
上图是入站身份验证流程,服务消费者调用Service时,Service作为服务提供者需要对消费者的令牌进行验证。具体流程如下:
这是本地的出站请求流程,Service作为服务消费者携带令牌访问其他后端服务。具体流程如下:
从耦合性,复杂性,可复用性,可维护性四个维度来看,现在的inbound和outbound authentication流程面临如下问题:
如何来解决这些问题呢,API Gateway是选项。
API网关鉴权
API网关位于客户端与各个微服务间,充当了反向代理的角色,将客户端请求路由到相应的微服务。与此同时,它可以完成安全,限流,缓存,日志,监控,重试,熔断等功能。API网关方式的核心要点是,所有的接入方和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。身份认证作为API网关中的一个组件,可以以模块的方式运行,也可以用微服务的方式运行。
如上图所示,当服务消费者需要请求服务提供者时,
相比于微服务系统自身鉴权,API网关鉴权可以来进行Inbound Authentication,从耦合性,复杂性,可复用性,可维护性四个维度来看比系统自身鉴权都有所改善。
API网关没有处理Outbound Authentication,服务提供者还是需要在自己服务端获取令牌来访问其他服务,所以令牌管理的耦合性,复杂性,可复用性,可维护性问题没有解决。另外如果API网关和服务提供者是通过网络通信,那么根据“零信任网络,永远不要信任网络并始终进行验证”原则,我们还是需要在API网关和服务提供者实施安全控制,增加了鉴权的复杂性。针对这些问题,Thoughtworks技术雷达里面收录了一种处于试验阶段的方案sidecars-for-endpoint-security,后面我们就叫它authentication sidecar pattern。
Authentication Sidecar Pattern
Sidecar模式是一种解耦的模式,比较适合系统运行在日益复杂的多云或混合云环境中,其中包含多个分布式组件和服务。如这些组件和服务是使用微服务架构开发并打包到容器中,部署在Kubernetes,Kubernetes将组成应用程序的容器分组为逻辑单元,以便于管理和发现。
如上图所示,sidecar附加到Service并为Service提供支持功能。Sidecar位于与Service相同的Kubernetes Pod中,并与Service共享相同的生命周期,与Service一起创建和淘汰。Ingress sidecar用于处理到附加到Service的入站请求。Egress sidecar用于处理Service到下游Service的出站请求。下面会通过对比系统自身鉴权和authentication sidecar模式,来对authentication sidecar进行分析。
上半部分的图是系统自身鉴权的入站身份认证流程,首先服务消费者从OAuth服务器获取令牌,然后携带令牌调用Service, Service验证令牌。下半部分的图是authentication sidecar的身份认证。基础设施级别: Kubernetes的Pod有一个ingress sidecar负责验证入站的令牌,authentication SDK从Service分离并放入ingress sidecar。整体的流程:
此外,Service中还有一个用于运行状况检查的Health check API。我们可以看到ingress sidecar的特性:
左半部分是系统自身鉴权系统出站请求流程,首先Service从OAuth服务器获取令牌,然后携带令牌调用其他后端微服务。右半部分是authentication sidecar的authentication token的管理。基础设施级别: Kubernetes的Pod有一个egress sidecar负责获取出站令牌,authentication SDK从Service分离并放入egress sidecar。整体的流程:
我们可以看到egress sidecar的特性:
上面是整个请求的全景图,上游可以是前端或后端服务消费者,Service是自己团队的应用程序,下游是服务提供者。Ingress和egress sidecar有独立的容器,和service容器一样都位于同一个Pod。
上图是系统自身鉴权到authentication sidecar的架构演进, 从耦合性,复杂性,重复实现,可维护性四个维度来看:
总结
本文分析了微服务间身份认证和令牌管理的系统自身鉴权,API网关鉴权和authentication sidecar的方案,痛点和好处。软件工程中不可能有任何“银弹” 解决软件的复杂度问题,这几种方案都有相关的条件和限制,下表是关于这三种方案的适用场景。
方案 | 适用场景 |
---|---|
系统自身鉴权 | 单体应用或各系统间没有太多服务通讯;需要快速完成的系统 |
API网关鉴权 | 所有的客户端和消费端都通过统一的网关接入微服务,只能进行Inbound Authentication |
Authentication sidecar | 企业内有很多分布式微服务并有容器化的部署;Service Mesh架构 |
针对现在分布式,微服务,容器化架构的流行,许多系统运行在日益复杂的多云或混合云环境中,其中包含多个分布式组件和服务。通过引入authentication sidecar,使得各自团队负责的Service代码更加简洁,解除了业务Service和authentication服务的耦合,在每一个的Service中消除了重复的authentication代码,有利于分布式和微服务系统的快速构建,开启了分布式和微服务架构的新体验。
本文分享自 ThoughtWorks洞见 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!