本文转自绿盟科技研究通讯公众号 《主流云原生微服务API网关成熟度与安全功能对比分析》

一. 概述

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

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

二. 开源软件

2.1 Ambassador

2.1.1 背景

Ambassador是基于Envoy代理构建的Kubernetes原生微服务API网关，其从设计之初就致力于支持需要频繁发布、监控、为终端用户更新服务的多个独立团队。Ambassador还可以用于处理Kubernetes ingress控制器和负载均衡。另外Ambassador在GitHub上拥有2.4K的star以及356的fork数量。

2.1.2 Ambassador架构

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

Ambassador工作流程[4]：

1. 服务所有者在Kubernetes中定义test.yaml文件配置路由规则。

2. 通过kubectl apply -f test.yaml将yaml文件作用于集群后，Kubernetes会通过API-Server组件将更改信息通知Ambassador。

3. Ambassador解析更改信息并将其转换为Envoy配置的中间信息。

4. 通过基于gRPC的聚合服务发现（ADS）API将中间信息转化为Envoy配置并传递至Envoy组件。

5. 流量经过重新配置的Envoy从而不会丢失任何连接。

2.1.3 安全功能

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

1. TLS加密

   Ambassador的TLS加密过程主要使用Openssl自签名证书，并将证书密钥存储至Kubernetes的Secret资源中，最后Ambassador利用Kubernetes的CRD资源TLSContext进行TLS声明以便对流量进行加密。

   Ambassador还使用第三方证书管理平台（Jetstack’s cert-manager）对证书进行定时更换更新等操作。

2. 认证授权

   Ambassador的认证授权过程是基于第三方插件支持的，首先需要部署第三方插件服务（定义一个Kubernetes的Deployment、Service对资源对象），然后在此基础上通过Kubernetes的Annotation机制将其关联到后端运行的服务中从而达到认证授权的目的。

   Ambassador同时还支持自定义过滤器实现细粒度OAuth/OIDC认证。

3. 限速

   Ambassador的限速服务通过委托第三方插件管理，与认证授权功能一样，需要先部署第三方插件服务，然后通过Annotation将限速服务与后端服务关联从而达到限速目的。

   Ambassador 同时还提供了细粒度的限速服务，主要用于对每个后端的服务进行独立管理及控制速率限制。

2.1.4 优势

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

2.1.5 不足

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

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

2.2 Zuul

2.2.1 背景

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

2.2.2 Zuul架构

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

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

2.2.3 安全功能

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

2.2.4 优势

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

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

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

2.2.5 不足

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在安全层面面临的现状。

2.3 Gloo

2.3.1 背景

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

2.3.2 Gloo架构

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

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

2.3.3 安全功能

1. TLS加密

   TLS加密与Ambassador类似，需要使用Openssl自签名证书，并且将证书密钥作为Kubernetes的secret资源，这样后端的服务将会自动绑定https 443端口并实时监听，当有http请求时则不会收到成功响应，因为http侦听器上不再有路由，此时Envoy将提供宽限期以排出http请求，完成排出后，http端口将关闭。

   Gloo由于支持无缝接入Istio，因此当Istio以auth方式部署时，所有的服务间通信则转化为双向TLS验证，大大增加了安全性。

2. 认证授权

   Gloo提供多种认证授权方式，主要有OAuth、JWT(JSON Web Tokens)、API Keys、OPA Authorization、LDAP、Custom Auth server、Plugin Auth。其中OPA Authorization（开放策略代理授权）与Kubernetes自身的RBAC机制相比，允许更细粒度的策略，与RBAC机制的详细比较可以参考官方文档。

3. 提供高级的限速服务

   Gloo还提供高级的限速服务，主要通过以下三种方式[9]：

   (1). Gloo API

   可对授权用户及匿名用户设置不同速率限制，覆盖面较广。

   (2）Envoy API

   Gloo默认的限速方式，因为Gloo以Envoy作为其数据平面，故可以使用Envoy限速API去完成。

   (3）Server Config

   默认情况下，Gloo内置的速率限制服务由Redis支持，对于全局速率限制Redis是一个不错的选择，因为它的延迟很短。但在用户需要跨数据中心进行限速这种场景下Redis不支持复制或多主站配置，因此可能无法达到目标。DynamoDB可以通过利用其内置的复制功能（DynamoDB全局表）来弥补这一不足。DynamoDB的设计是为毫秒级延迟而构建。

4. WAF

   Gloo使用第三方WAF开源软件ModSecurity 3.0版本进行Web应用的防护，ModSecurity 3.0提供简单的原语对传入API网关的流量进行检测，并且其自身包含许多公用的规则集非常强大，例如OWASP核心规则集。

5. 数据丢失防护（DLP）

   DLP全称为Data Loss Prevention，是一种确保敏感数据泄漏的方法，而具体实现方式是在响应体中进行一系列的正则表达式替换来完成。

6. 跨域访问 Gloo实现跨域访问限制也非常简单，只需在对应下发规则的yaml文件中添加cors配置项即可。

2.3.4 优势

1. Gloo控制平面研发团队为Envoy资深专家，与开源项目Envoy紧密结合，可以说是做到实时更新。

2. 兼容多平台运行，比如 Kubernetes，AWS Lambda，VM，Terraform，EC2，Consul等。

3. 被选为Knative项目的第一个Istio替代品。

4. Gloo的控制平面与运行API网关分离，这使得其可以被独立保护和扩展。

5. Gloo 可以发现其它类型的端点，比如 AWS Lambdas。当有混合搭配 Kubernetes与Serverless时，Gloo可作为一种选择。

6. Gloo在安全性上表现突出，基本传统API网关具备的特性Gloo都包含。

2.3.5 不足

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

2.4 Kong

2.4.1 背景

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

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

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

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

2.4.2 Kong Ingress控制器架构设计

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资源以便正确代理所有流量，下图描述了映射关系：

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

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

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

2.4.3 安全功能

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

安全插件

1. 僵尸网络防护插件

2. 防止跨域类插件

3. IP黑白名单限制插件

4. JWT身份验证插件

5. WEB应用防火墙插件

6. 防恶意软件类插件

7. AI防护插件（主要针对微服务以及API）

8. Kong的API防护插件

9. 针对xss、sql注入、csrf、ddos等常见Web攻击类插件

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

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

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

2.4.4 优势

1. 火热的开源社区

2. 丰富健全的文档

3. 实践落地经验多

4. 覆盖面广，在Serverless、Service mesh、Kubernetes、Microsoft Azure等主流云原生环境中都有涉及相应的子项目研究

5. 统一的Admin API管理

6. 安全功能全面，插件的生态很丰富

2.4.5 不足

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

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

三．开源软件对比

为了阅读起来清晰明了，笔者从基本项、规则配置、部署、可扩展性、基本功能、安全功能这六方面分别对Ambassador、Zuul、Gloo、Kong四者做以比对并汇总为一张表格，如下所示：

四．总结

通过将Ambassador、Zuul、Gloo、Kong这四款开源软件进行对比，就和Kubernetes及微服务的粘合度来讲，Ambassador和Gloo都是不错的选择，两者都是Kubernetes原生微服务API网关，也都是基于Envoy开发各自的控制平面。Ambassador相比Gloo开源时间要更悠久些，成熟度上Ambassador要更高些，如果你的微服务运行在Kubernetes平台上，两者都是不错的选择；如果你的微服务框架是Spring Cloud，Zuul一定是最佳选择，因为Zuul是Spring Cloud默认的API网关，另外Zuul的受众面也很广，生态相对较为成熟。Kong作为API网关的鼻祖，不论社区活跃度、软件成熟度都可称为API网关市场上的佼佼者，其插件机制因为简单易用引来了不少开发者的追随，另外Kong也可作为Kubernetes Ingress控制器。Kong始终保持着高性能、扩展性强的特点并紧随微服务时代变换的脚步，是微服务API网关的绝佳选择。

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

1. Web应用防火墙（CSRF、恶意软件、XSS、DDoS、僵尸网络、木马蠕虫、多域名验证、异常流量分析）

2. 访问控制（CORS、IP黑白名单限制、ACL检查）

3. 认证授权（OAuth、OIDC、JWT）

4. SSL证书管理、TLS加密

5. 数据丢失防护

6. 限速服务

开源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/

× Ming Blog

真诚赞赏，手留余香

1元 2元 5元 10元 30元 50元

2元

• Next Post →