利用istio 出口网关实现eBay应用微隔离之实践分享

为了提升网络安全性，传统的隔离方案中企业的网络会分成若干个不同的安全级别的区域。每个区域之间使用防火墙等设备或者技术隔离开，只允许授权的流量通过。该方案的特点是隔离只在不同的安全区域之间生效，如果是两个在相同安全区域内的应用，它们之间的流量不受控制。

如图1所示，有两个不同的安全信任域1和2，由一堵防火墙隔离开。当应用A想访问应用C时，必须申请防火墙规则才能够放行，否则默认下无法访问。但是如果A想访问B，由于它们是在同一个安全信任域内，流量无需穿越防火墙，所以不需要申请规则，默认就能访问。这种隔离被称之为宏隔离(macro-segmentation)。

图1 宏隔离安全架构

随着企业对安全的需求日益强烈，以及网络架构的日趋复杂，传统的宏隔离架构显得越来越力不从心。一个主要的问题是当黑客突破了一个安全信任域的一点的时候，它就能在整个区域内畅通无阻的活动。于是，一个新的架构应运而生，它限定任意两个应用之间的访问都需要规则才行，从而降低风险的暴露面。对应于宏隔离，这种新的架构叫做微隔离(micro-segmentation)。

图2是一个微隔离架构示例。这里访问策略控制点由区域边界的防火墙变成了每一个应用边界的防火墙，每一个应用自己成为了一个安全信任域。无论应用A想访问B还是C，它都需要申请规则才行。

图2 微隔离安全架构

 基于IP的隔离  

基于IP的隔离是一项非常成熟的技术。它控制一组特定IP作为源来访问另一组特定IP，或者允许指定源IP访问本机和指定目标IP作为出口流量。大名鼎鼎的iptables就是这项技术的软件实现。另外，很多厂商开发了硬件防火墙，比如paloalto，juniper等。这项技术在宏隔离的架构中早已广泛应用。在微隔离领域，它也成为了最直接的方案。eBay的第一代微隔离就是采用了基于IP的隔离技术。

这项技术的关键点在于把IP作为流量源和目标的标识来制定规则。比如有一个交易系统应用A，IP是10.0.0.1，它需要访问一个数据库B，IP是10.1.0.1。这里把IP 10.0.0.1 作为应用A的标识，把IP 10.1.0.1 作为数据库B的标识，制定规则10.0.0.1可以访问10.1.0.1。

但这里存在一个潜在问题。我们看这条IP规则，真正的需求是控制这两个IP之间的访问吗？不是，我们真想要的是A能够访问B，IP只是被借用来作为标识。所以我们要做一层应用到IP转换才行。

在宏隔离的架构中，每个信任域会被分配到一个网段，这些网段往往是相对静态，不常变动的。在微隔离架构中，网段退化成一个/32的IP，如果这些IP能够相对固定，那么基于IP的隔离也能很好的工作。然而我们进入了云计算时代，并使用kubernetes作为eBay的云平台。在k8s的世界里，Pod的生命周期很短暂，而Pod IP不再固定，导致应用到IP的转换变得非常频繁，每当应用发布时，Pod的IP都会发生变化，该Pod的上下游所有的对端规则都要更新。

在图3这个例子中，我们使用了iptables作为隔离方案，允许应用A的Pod访问应用B的Pod。当应用A发布时，A的IP发生变更，我们要求它的对端B的iptables也发生变更，把A的IP从10.0.0.1改为10.0.0.2。

而在实际应用场景中，每一个Pod的上下游Pod总数成百上千，而一个大一些的应用也会有成百上千个Pod，每一次应用发布，都会导致数以十万计的iptables的变更，这些变更开销十分庞大，而且延迟时间不可控，更糟的是，要确保所有的iptables变更全部成功完成的开销更大，甚至几乎不可能。

图3 基于IP的隔离技术，当应用IP变更时要求对端更新iptables

 基于应用ID的隔离  

根据上文讨论可知，问题的根源在于我们实际上想控制应用之间的访问规则，却选择了不稳定的IP来作为应用的身份标识。那么我们可以使用一个稳定的，更加直接的代表一个应用的标识吗？比如，我们给每一个应用定义一个ID，这个应用所有的Pod都共享这个ID，并且不会变化，那问题就解决了。

图4 基于应用ID的隔离技术，当应用IP变更时无需对端更新规则

由图4可见，如果我们能够找到一个应用ID，并以此ID来定义规则的时候，当应用发布IP改变，上下游节点的规则都不需要变化，大大降低了复杂度，从而提高了可靠性。

这里的重点和难点是怎么找到一个合适的ID来标识应用，并使用这个ID来写规则。下面我们来分享一个eBay云平台安全团队使用istio出口网关来实现基于应用ID来做微隔离的案例。

 场景描述  

eBay第一代的微隔离架构是利用IP来实现隔离的。随着上k8s的应用规模越来越大，每次应用发布后刷新各个节点的IP速度越来越慢，并且容易出错。性能瓶颈首先出现在硬件防火墙上，eBay目前有不少应用使用了硬件负载均衡器(Load balancer)，为了隔离这些LB上的VIP，eBay云平台安全团队使用了硬件防火墙，在上面配置了基于IP的访问规则。根据微隔离的要求，这些IP都是/32的Pod IP，每当Pod IP发生变化后，团队都需要去更新这些硬件防火墙上的IP。这些墙有上万条规则和几十万的IP，更新IP非常耗时，当站点上有大量Pod重建IP变化时，有时需要等几个小时才能全部更新完毕。

我们想首先使用基于应用ID的技术来解决硬件防火墙的问题。硬件墙是一个商业产品，我们没有办法对其进行改造，所以我们在Pod和硬件墙之间设一个代理，把规则前移到这个代理上，同时让硬件墙信任这个代理。考虑到eBay的云原生应用大都使用了istio来管理，istio本身有丰富的认证和授权功能，因此我们决定使用istio出口网关来担任这个代理的角色。

在下面这个例子中，我们有一个user应用要访问login应用，user部署在k8s上面，并且被istio管理，有sidecar来控制流量。login应用有一个vip在硬件LB上，被一个硬件防火墙保护。我们希望流量从user Pod出来后，先到出口网关，然后再到login的vip。硬件墙允许出口网关的IP访问login vip，在出口网关上我们配置规则允许user访问login。

 定义访问规则  

出口网关的规则可以使用istio authorizationpolicy来实现，选取合适的ID来代表应用是关键。authorizationpolicy也支持IP，但是如果使用IP，那么user Pod IP发生变化时，authorizationpolicy也要更新，这不是我们想要的。

Istio支持spiffeID来标识应用。在istio中，spiffeID的格式是<trustdomain>/ns/<nsname>/sa/<saname>，可见这个ID由信任域(trustdomain)，名称空间(namespace)和服务账号(serviceaccount)组成。在ebay的k8s集群，我们把相同作用和安全级别的网络区域划为一个信任域，比如dev，production等。对于同一个应用，namespace和serviceaccount也是相同的。那么对于我们生产环境的user应用来说，它的spiffe ID就是production/ns/user/sa/user，无论user的pod和ip怎么变化，这个ID都是稳定的，不会改变。

对于目标应用login来说，选择vip fqdn来做为标识更为直观和有效。login的fqdn是login.vip.ebay.com。客户端都是使用这个名字而不是IP来访问的，无论实际login应用的pod ip和vip IP怎么变化，这个fqdn也是稳定的。

因此，我们可以通过如下istio authorizationpolicy规则来授权这个访问

    from:

    - source:

        principals:

        - production/ns/user/sa/user

    to:

    - operation:

        hosts:

        - login.vip.ebay.com

 识别应用的ID  

当出口网关有了上述规则定义后，它就可以执行规则了。对于每一个数据包，出口网关先要识别出源和目的的ID，目的端的fqdn比较容易，直接从请求包里面就可以找到，那么spiffe ID怎么来的呢？

这里我们借助于istio的mTLS功能，istio会在源pod的envoy sidecar和出口网关之间建立双向TLS认证，也就是mTLS。因此出口网关接收到的数据包中会包含源pod的证书，证书上给予这个Pod的ID就是它的spiffeID。这个证书是由istiod签署的，出口网关可以验证并解开这个包得到spiffe ID。mTLS机制不但顺利的把ID放入数据包中传输给了出口网关，也保证了ID的可靠性，别人没有办法冒充这个ID放入其它pod的请求中。

 路由到出口网关  

出口网关的规则都配好以后，下一步就要让数据流经出口网关。在默认情况下，user应用pod发出的请求是login.vip.ebay.com，那数据包就直奔目的地去了，我们要把这个包劫持，转往出口网关。这个工作也是有istio在user的pod上配置的envoy sidecar来执行。我们可以配置如下istio virtualservice对象来执行路由

  hosts:

  - login.vip.ebay.com

  http:

  - match:

      - port: 443

      route:

      - destination:

    host: istio-egressgateway.production.svc

    port:

          number: 443

这段virtualservice对象配置说明，当发出的请求目标是login.vip.ebay.com，端口443时，转发到istio-egressgateway.production.svc端口443。

 整体流程  

综合上面几点，我们得到了数据面整体流程图：

图5 istio出口网关实现微隔离整体流程图

 对Https请求的优化  

在istio的推荐应用场景中，社区希望应用开发者专注于功能的开发，而把安全性交给istio来搞定。因此，应用程序应该直接发起http请求，由istio mTLS来加密保障通信安全。然而，对于现有应用，程序往往已经发起https请求，这个时候如果要求它们改回到http，那对应用开发者就很不便。而且理想状况下我们的云是否应用istio网格应该对应用透明，我们很难要求应用开发者提供一个http的istio专供版本。

在上面的解决方案中，即使用户直接发起https请求，它仍然能够工作。istio mTLS并不强制要求原始数据一定是非加密http请求，它可以简单的把请求当作一个纯TCP请求，在上面做mTLS。然后在出口网关解开mTLS后，把里面的内容转发给目的端。这时相当于原始http请求经过了2层TLS，内层TLS在user应用建立后，一直到终点login应用才被解开。

但是这样也有缺点，主要是2个。一是envoy sidecar和出口网关对于该 http请求不可见，只能看到加密后的https包。envoy中的一些基于http请求的路径，参数，报头，返回值等信息做路由，过滤或者熔断等方案统统不可用，也无法监控请求成功率等指标并告警。二是目的应用只能看到出口网关的IP，并没有办法知道实际上真正的请求方。如果出口网关能够解开tls看到http请求，那么它就可以把原始的请求者IP放到http报头中传递给后端。

那么出口网关有办法解开内层的TLS么，理论上是可行的，它可以假装自己是login，只要源pod user信任出口网关的证书就行。但这样风险很大，如果这个证书泄漏，黑客可以利用这个证书冒充login服务去欺骗其它客户端。我们可以降低这个证书的有效域到pod的范围，即在user pod生成的时候，通过初始化容器(init container)当场创建一个CA并签一个证书给envoy sidecar，然后把CA挂载到user应用容器上。这样的话，user应用容器就可以信任本pod的envoysidecar证书，并且这个证书只在pod内有效。即使证书泄漏出去，其它pod没有这个CA，所以也不会信任这张证书。

图6 envoy sidecar本地终结https

这时，数据面流程变成了应用pod user发起https请求，本地envoy sidecar终结这个https请求，然后转发给出口网关并发起mTLS请求，如图6所示。

在本文中，我们先介绍了微隔离的概念和为什么要使用应用ID来做微隔离，然后详细介绍了eBay怎么使用istio出口网关来实现基于应用ID的微隔离。目前这项方案已经在eBay的生产环境中运行了大半年，有超过一百个应用使用了该方案，使应用部署等待防火墙的时间从小时级下降到秒级。

然而这个方案也有局限性，它要求应用要上istio网格。目前eBay绝大多数web应用都上了istio服务网格，但是还是有很多非web应用，比如数据库等不适合上istio的。这些服务无法借助istio来实现基于ID的微隔离。另外，istio的方案是在7层做的隔离，非授权请求已经通过了下层网络协议栈造成了开销，使得其对抗DDoS攻击时性能降低，envoy容易被打爆。理想状态下，非授权请求应该尽早被截获并丢弃，基于IP的微隔离在4层就能生效，使其在性能和安全性上要优于基于istio的7层微隔离方案。

那么，有没有办法摆脱istio的依赖，并在4层就做到隔离，同时使用基于应用ID来设定规则呢？答案是有的，eBay云平台安全团队正在结合业界最新技术研究开发下一代微隔离产品。届时我们将推出新的文章介绍此项技术，敬请期待：）