vlambda博客
学习文章列表

在整个微服务架构中，API网关充当着非常重要的一环，它不仅要负责外部所有的流量接入，同时还要在网关入口处根据不同类型请求提供流量控制、日志收集、性能分析、速率限制、熔断、重试等细粒度的控制行为。API网关一方面将外部访问与微服务进行了隔离，保障了后台微服务的安全，另一方面也节省了后端服务的开发成本，有益于进行应用层面的扩展。与此同时，API网关也应具备解决外界访问带来的安全问题，例如TLS加密、数据丢失、跨域访问、认证授权、访问控制等。本文尝试分析目前主流的云原生微服务API网关成熟度以及各自具备的安全功能，并比较各自带来的优劣，尤其在安全层面上，开源软件都做了哪些工作，是否全面，若不全面我们又该如何弥补。

因Kubernetes具备自动化部署、大规模可伸缩、应用容器化管理等优势加上近年来持续保持的高关注度，其成为了微服务标配的运行平台。基本围绕容器生态衍生的各类工具都以在Kubernetes平台上运行为核心去设计，所以我们以此为前提对目前市场比较火热的Ambassador、Zuul、Kong、Gloo这四个开源软件进行分析比对。

图1 Ambassador架构

Ambassador架构分为控制平面和数据平面，数据平面以Envoy为代理对所有实际流量进行转发，控制平面负责将用户配置（通过Kubernetes annotations的形式）转化为Envoy配置。

Ambassador工作流程[4]：

Ambassador目前支持的安全功能主要涉及TLS加密、认证授权、限速三方面：

Ambassador为Kubernetes原生微服务API网关，因此Kubernetes也为Ambassador带来了许多优势，比如Ambassador可将Envoy配置存储至Kubernetes的Etcd组件中从而避免了数据库组件的引入，另外Ambassador以Kubernetes Deployment资源方式部署，因此是无状态的，可以按需对Pod进行扩缩容，相比于以单个集中式控制平面来管理数据平面的多个实例（Istio）来说增加了高可用性。再者Ambassador将Envoy引入作为其数据平面解决了L7层代理无法解决的一些微服务场景，整体提升了流量代理的性能。

因Ambassador基于Kubernetes进行设计，所以Kubernetes为其带来好处的同时也间接说明Ambassador与Kubernetes紧耦合，Ambassador更像是Kubernetes生态下的衍生品，针对微服务和云原生模式，但是其对除过Kubernetes以外的平台支持欠佳，目前官网上还没说明对Microsoft Azure、Openshift、Cloud Foundry这些主流云平台的支持。

安全层面来说，Ambassador在访问控制、TLS加密、限速服务三方面均有所涉及，但比较重要的入口流量异常检测、Web应用防护、黑白名单访问控制等功能目前还未见支持，可见Ambassador在安全方面考虑还不是很周全，另外Ambassador支持的安全插件也没有形成生态，这和Ambassador的开源时间也有一定关系，毕竟没有太多的落地实践，仍需时间的考验。

Zuul是Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器，在2014年被Pivotal集成至Spring Cloud微服务框架中。其在GitHub上拥有8.5K的star以及1.7K的fork数量。Zuul设计理念在于实现动态路由、监视、弹性、安全性等功能, 其亮点在于可动态发布的过滤器机制。

图2 Zuul架构

Zuul的中心是一系列过滤器，能够在HTTP请求和响应的路由过程中执行一系列操作，因此Zuul提供了一个框架，可对过滤器进行动态的加载，编译，运行。过滤器之间没有直接的相互通信。他们是通过一个RequestContext的静态类来进行数据传递[10]。

Zuul过滤器是由Groovy[1]写成，这些过滤器文件被放在Zuul Server上的特定目录下面，Zuul会定期轮询这些目录，修改过的过滤器会动态的加载到Zuul Server中以便过滤请求使用，从而具备动态发布的过滤器机制。

Zuul默认的过滤器有很多种，但这些并不能满足特殊安全场景下的需求，因此需要开发者自定义安全过滤器或使用兼容Spring Cloud的安全框架去处理，鉴于Spring Cloud已经是一套成熟的微服务框架，因此相应开源安全产品也非常多，典型的像Spring Security、Shiro安全框架在处理认证、授权、管理会话、管理证书、以及通信加密时都具备非常好的效果。Spring Security因更适用于微服务架构故目前使用者较多，Spring Security在其设计中通过提供一组原语进而构建安全的应用程序及服务，且操作简单，类似Kubernetes，Spring Security也是声明性模型，用于对流量进行更细粒度层面的处理。

Zuul基于java开发，java由于拥有大量群众基础，因此对大多数程序员友好。

API应具备多种定制化流量控制，由于Spring cloud基于Java平台的原因，故对于绝大多数开发人员来说兼容性高。

开源时间长，落地实践多，生产环境下运行稳定，坑少。

Zuul出世尚早，云原生概念还不普及，因此没有针对云原生的理念去设计API网关，也没有原生兼容Kubernetes、Mesos等容器编排平台，网关本身也不是CRD资源。再者就是Spring cloud支持java，所以对于Zuul来说扩展性低。

有些读者可能会有疑问，既然Zuul是基于Spring Cloud微服务框架设计的API网关，那么在目前流行的Kubernetes平台上岂不是发挥不了其优势了，其实Spring Cloud也考虑过这点，如何在脱离Spring Cloud的情况下在Kubernetes上使用Zuul，于是Spring旗下开发了一个子项目Spring cloud Kubernetes，其作用就是将Kubernetes中的服务模型映射至Spring cloud服务模型中，从而可以使用Spring cloud的sdk去实现对Kubernetes服务的管理。借助于Spring cloud Kubernetes项目，Zuul可以和Kubernetes融合并实现API网关能力，也可勉强称作云原生API网关。但是换个角度想问题， Kubernetes天然具备微服务能力，且有许多相应的原生API网关，我们为何不去使用呢？在Spring Cloud与Kubernetes中间强加一层适配器似乎有点多此一举的意思。

就安全层面而言，Zuul通过安全框架可以实现绝大多数安全功能，但因为这些安全框架多基于Java编写，很难应用到在以Go语言为主的云原生平台中，这也是Zuul在安全层面面临的现状。

Gloo是由solo公司开发，以Envoy开源技术为基础打造的一款API网关开源软件，solo公司在Gartner 2019峰会上被评为最酷供应商，其在GitHub上拥有1.9K的star以及130K的fork数量。

图3 Gloo架构

因与Ambassador的架构几乎一样，在此不做赘述，下面我们以Gloo的组件架构说明：

图4 Gloo组件架构

由Gloo的组件架构可看出核心部分为Translation Engine, Gloo的控制平面其实就是Translation Engine和Envoy xDS服务器结合体，它为数据平面组件Envoy提供配置。Gloo遵循基于事件的体系结构，通过Config Watcher、Secret Watcher、Endpoint Discovery监视各种配置源进行更新，并通过v2 gRPC更新配置以便及时对Envoy做出响应。最终Envoy会将动态更新的配置下发给上游的服务[9]。

Gloo目前支持的安全功能主要为TLS加密、认证授权、限速、WAF、数据丢失防护、CORS、开放策略代理这几方面：

安全层面来说，Gloo和Ambassador虽然都是基于Envoy做流量管理且均属于Kubernetes原生API网关，但在安全功能提供上却有着明显差异，Gloo几乎将全部的安全功能都考虑进去了，并且在每个功能点上都有相应扩展，只是目前社区版本只发布到v1.0.0，还没有成熟的落地案例，所以具体安全层面可以达到什么样的效果还有待观察。不过可以作为Knative项目的第一个Istio替代品，说明Gloo的潜力也是不可估量的，笔者个人还是比较看好Gloo。

Kong是一个云原生，快速可扩展的分布式微服务抽象层（通常被称作API网关，API中间件或服务网格），其核心价值是高性能和可扩展性，于2015年作为一个开源项目提供。Kong在GitHub上拥有24.2K的star以及3.1K的fork数量。

简单的说，Kong在Nginx的反向代理基础上，通过Lua实现了脚本化的扩展，同时所有管理功能都是通过REST来实现。其内部还使用了大量的缓存，所以基本没有阻塞式的操作，性能非常优秀。

Kong的扩展性主要体现在其插件机制，可方便的为路由添加各种插件，Kong的官网有一页专门体现了其支持的插件，如下图所示：

图5 Kong官网Plugin

由于本文主要围绕Kubernetes云原生API网关进行分析，因此架构设计着重说明Kong在Kubernetes上的使用场景。

Kong可以作为Kubernetes的Ingress控制器,  Kong Ingress控制器在集群中通过创建Ingress资源配置Kong。

Kong Ingress控制器由两个组件构成：

1. Kong

用于处理所有入出口流量的核心代理

2. Controller

通过Controller将代理配置从Kubernetes同步到Kong

Kong Ingress控制器的功能不仅代理Kubernetes集群的入出口流量，它还可以在独立安装中配置插件，负载均衡，健康检查并充分利用Kong提供的所有功能。

其工作方式为：

1. Controller监听Kubernetes集群内部发生的更改（pod、svc等变化），并响应这些更改，最后更新Kong以便正确代理所有流量。

2. Kong包含动态更新配置的机制，以响应围绕Kubernetes集群发生的更改，进而可实时对流量进行管控。

Kong与Kubernetes资源映射转换机制

在Kong Ingress控制器工作周期中，最重要的一环为如何将Kubernetes资源映射至Kong资源以便正确代理所有流量，下图描述了映射关系：

图7 Kong与Kubernetes资源映射

Kubernetes中的Ingress资源定义了一组代理流量的规则，这些规则对应于Kong中的路由配置。

Kubernetes运行的服务实际上是一个应用程序，在Kubernetes中对应为一组Pod资源，其映射到Kong中主要包含两个资源：Service和Upstream。Kong中的Service资源保存用于与上游服务进行通信的协议信息及其它各种特定于协议的设置。Upstream资源定义负载均衡和健康检查行为。

Kubernetes中的Pod资源映射为Kong上游的目标服务，Kong会在Pod中做负载均衡，这说明所有经过Kong的请求都不会通过kube-proxy进行重定向而是直接定向到对应的pod。

由于Kong是一个通过插件扩展其功能层面的软件，因此Kong也提供相应的安全插件，笔者统计了目前Kong提供的安全插件：

Kong在安全方面考虑的非常周全，可以说常见的攻击都有相应的防护插件，这些插件的使用也非常简单，Kong提供dashboard以便管理人员可以快速运维，同时Kong也提供强大的Admin API用于对插件以及资源做管理：

在service上启动一个IP黑白名单限制插件只需在终端执行：

1$ curl -X POST http://kong:8001/services/{service}/plugins \
2
3--data "name=ip-restriction"  \
4
5--data "config.whitelist=54.13.21.1" \
6
7--data "config.whitelist=143.1.0.0/24"

Kong本身为企业级的API网关，因此自身比较重，学习曲线相对陡峭。

安全层面而言，Kong作为一款历史悠久的API网关，具有丰富的安全插件生态和实践经验，且插件范围覆盖面广，基本的安全功能Kong都考虑在内了，唯一不足就是Kong作为一款传统的微服务API网关，在复杂多变的云原生环境下无法充分发挥其优势，虽然旗下也开发了子项目kubernetes-ingress-controller，但其star及fork数量相比于Kong相差甚远，但以Kong开源多年的经验，kubernetes-ingress-controller的发展不容小觑，在未来很可能会是最受瞩目的云原生API网关之一。

反观这些开源软件在安全层面的考虑，首先，笔者认为作为一款优秀的云原生API网关，应具备以下六个基本功能：

开源API网关虽然已能解决很多安全问题，但具体使用选择还是需要依据具体的业务场景，目前看来主流的云原生API网关在对入口流量的异常检测上涉及还不多，我们可以以此为突破点，将流量异常检测部分放入其中从而可以达到更好的防护效果；再者开源的WAF通常部署困难对用户的专业知识要求过高，并且基本都是基于规则的检测，对于网页篡改检测、cookie加密等方面都缺乏的相应防护手段，另外开源WAF的告警日志呈现也不是非常人性化，如果读者所在企业有WAF产品，其实可以考虑企业侧API网关的安全，让API网关能力最大化。

参考文献:

[1].http://openresty.org/cn/

[2].https://www.lua.org/about.html

[3].https://www.datawire.io/

[4].https://www.getambassador.io/docs/

[5].https://learnk8s.io/kubernetes-ingress-api-gateway

[6].https://konghq.com/

[7].https://www.solo.io/

[8].https://docs.solo.io/gloo/latest/[lw6] 

[9].http://blog.didispace.com/api-gateway-Zuul-1-zuul-2-how-to-choose/