云原生环境下的API业务安全思考

一. 概述

针对单体架构的应用，安全防护往往在边界网关设备处。随着业务需求的不断变化以及技术的持续更新，企业应用开始从单体架构向微服务架构转变。不同应用模块可以根据业务规模进行动态扩缩容，与此同时，微服务应用也为API安全防护带来了新的挑战。

笔者认为，微服务应用API安全防护相比传统API安全防护主要增加了以下几类挑战：

1. 随着服务更细颗粒度的划分，API接口的数量激增及调用关系的复杂，API管理将变得更加困难；

2. 服务间调用的不断增多使得利用API漏洞进行横向攻击的风险也不断增加，从而增加了防御难度；

3. 传统防御方式往往是在网络边界对南北向的流量进行检测，微服务间产生的东西向流量无法通过传统边界防御的方式检测；

如上所述，我们需要一种更细粒度的适用于微服务环境下的全流量的API防护方法。本文将首先介绍传统应用API 安全防护方法，进而引出云原生环境下微服务应用API安全防护方法，最后通过实际案例对微服务应用API安全防护方法进行剖析解读，希望可以引发大家更多的思考。

二. API安全防护

API（ApplicationProgramming Interface）作为程序之间交互的桥梁，承担着数据传输的重大作用。越来越多的安全问题都来自于API泄露，API设计缺陷等问题。微服务环境下，API数量的激增为系统的安全风险带来新的挑战。OWASP组织总结的API 安全风险Top 10[1]如表1所示：

表1

对于API防护也主要集中在以下几个方面：

1. 身份认证：可靠的身份认证及权限控制机制

2. 访问控制：对发起请求的对象，请求的速率进行准确的访问控制

3. 安全防护：传统Web安全风险的防护，SQL注入，XSS，CSRF等

4. 日志记录：对请求的链路进行完善的日志记录

5. 配置管理：对API 参数、调用链路、版本等进行有效管理

三. 传统API防护方案

在传统的网络架构中，内外网一般有明确的网络边界。常见的安全防护设备，例如WAF，防火墙，API网关等，都会在网络边界搭建来实现安全防护。主要防护进出内网的南北向流量，对于集群内部的API调用行为无法做到有效的防护。因此，一旦网络内部的一台机器的沦陷，会导致整个边界类型的API防护机制的失效。

图1

四. 微服务应用API治理与安全防护

在微服务环境下，存在着大量的服务之间的调用。这时，内部服务的API调用的安全风险就不得不考虑进去。同时，在云原生环境中，内外网边界逐渐模糊，更多的API会暴露在云上。随着API暴露面的增加，API被攻击的风险也大大增加，传统的南北向的边界流量的防护体系在云原生环境下的防护将会显得力不从心。因此我们需要一种更细粒度的适用于微服务环境下的全流量的API防护的方案。

4.1微服务治理

在微服务环境下，面对众多数据的微服务API，我们首先要解决的就是服务发现以及负载均衡的问题。

即如何发现服务的提供者、如何转发服务调用方发起的请求。目前业界主要有三种服务发现的模式。

1.集中代理

提供统一代理入口，一般通过域名解析的方式由集中代理实现服务的负载均衡转发

2.客户端代理

该模式通过独立中心的服务注册组件实现服务发现，负载均衡是在客户端自己独自实现

3.Service Mesh模式

该模式和客户端代理模式有点相似，也是通过独立中心的服务注册组件实现服务发现，但是负载均衡是使用单独的进程，通常被称为Sidecar，统一实现。

表2

集中代理模式，对业务变动较小，实现较为简单，但是存在集中单点的风险，且对集中代理的要求较高。客户端代理模式可以有效解决集中代理的单点的问题，同时直接调用服务提供者，可以降低网络开销，但是负载均衡需要自己实现，提升了实现复杂度，客户端比较复杂，不易于管理。Service Mesh弥补了两者的不足，通过Sidecar的模式做到负载均衡的统一。

4.2Service Mesh

ServiceMesh这个词的创始人William Morgan对ServiceMesh定义是：

“服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。”

Service Mesh 在微服务的基础上加上了一个网络代理，所有的流量都在Sidecar上完成，Sidecar完成服务发现，负载均衡，智能路由，故障注入，熔断等动能，从而微服务只需要注重业务实现。

Service Mesh的架构如下图2所示：

图2

从该架构可以看出，Service Mesh架构的设计为安全防护提供了很好的入口 ，在Sidecar中，我们可以完成上文提到的身份认证、访问控制、访问控制、日志记录、配置管理等API防护功能。目前比较知名的项目有Linkerd，Envoy，Istio，HashiCorp Consul等。

4.3Istio

Istio[2]就是目前受Google/IBM 等大厂支持和推进的一个 ServiceMesh开源框架组合。Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，而不需要对服务的代码做任何改动。Istio官方[3]对Istio的架构描述如下图3：

Istio在逻辑上分为数据平面和控制平面，控制平面主要实现微服务管理需要的服务发现的功能，数据平面的Envoy以Sidecar的模式提供负载均衡的功能。

图3

4.4Envoy

其中Envoy[3]是Istio的核心组件之一，以Sidecar的方式与服务运行在一起，对服务的流量进行拦截转发。具有路由，流量控制等强大特性。Envoy主要面向SOA（面向服务的架构）的网络代理，所以非常适用于微服务，其主要是用来调解ServiceMesh中所有服务的入站和出站流量。

图4

Envoy流量走向，从上图4可以看出，所有流经后端业务容器的流量都会被Envoy劫持，流经各种Envoy的过滤器（EnvoyFilter），最终流量再转发到业务容器。Envoy的流量处理都是通过各种过滤器来实现。

过滤器分为两个类别：

1. 网络过滤器（L3/L4），是Envoy网络连接处理的核心

2. HTTP过滤器（L7），由特殊的网络过滤器HttpConnectionManager管理，专门处理HTTP1/HTTP2/gRPC请求

关于Envoy的详细介绍可以参阅往期文章：【Istio系列二：Envoy组件分析】

4.5安全防护

虽然Service Mesh架构的出现，有效解决了微服务治理的问题，但是还是缺失API安全风险防护所需的访问控制、安全防护等功能。得益于Envoy接管了进出微服务的所有的流量以及Envoy的过滤器的机制，只需要在Envoy的过滤器中实现API安全防护的能力，我们就得到了一个微服务环境下的全流量的安全防护体系。

图5

数据平面数据流走向如图5所示：

1. 请求发送至Pod,Envoy截获此请求

2. 请求经过Envoy事先定义的 Filter，Envoyfilter官方提供了多种实现方式[4]，常用的有lua，wasm等

3. Filter对请求流量进行检测，判断是否是恶意流量，对非法行为直接阻拦，合法行为放行转发到业务容器

4. 业务容器接受到正常请求处理完，返回响应报文

5. Filter对响应流量进行检测，判断是否是恶意流量，对非法行为直接阻拦，合法行为放行响应给请求方

五. 案例

号链接特性”与“Kubernetes自身代码逻辑”两部分结合的产物。符号链接引起的问题并不新鲜，这里它与虚拟化隔离技术碰撞出了逃逸问题，以前还曾有过在传统主机安全领域与SUID概念碰撞出的权限提升问题等[11]。

5.1内置过滤器

通过内置过滤器，我们可以在不编写代码的前提下，只需要通过配置项，就可以对流经Envoy的API请求进行防护。

假设为了解决数据安全风险，某请求接口需要添加token，利用Envoy的过滤器就可以对特定请求添加token。

具体EnvoyFilter配置如下：

```yaml
apiVersion:networking.istio.io/v1alpha3
kind:EnvoyFilter
metadata:
  name: add-header
  namespace: <user-namespace>
spec:
  configPatches:
  - applyTo: VIRTUAL_HOST
    match:
      context: SIDECAR_OUTBOUND
      routeConfiguration:
        vhost:
          name: www.test.com:8080
          route:
            name: default
    patch:
      operation: MERGE
      value:
        request_headers_to_add:
        - append: true
          header:
            key: "X-AUTH-TOKEN"
            value: token

```

5.2自定义过滤器

在更复杂的场景下，通过Envoy默认的Filter无法达到我们的需求，这时候我们希望能通过自定义的代码来实现更定制化的业务逻辑。

通过Envoy提供的lua或者wasm的过滤器。我们可以直接编写lua代码，或者将C++、resty代码编译成WebAssembly代码，实现自定义的过滤器。

假设发现特定接口有信息泄露的风险，在服务修复前，需要对调用该接口的所有请求进行拦截处理。利用Envoy的http_filter的 lua扩展，我们可以很容易的对包含特定特征的请求进行拦截。

具体EnvoyFilter配置如下：

```yaml
apiVersion:networking.istio.io/v1alpha3
kind:EnvoyFilter
metadata:
  name: test-envoyfilter
  namespace: test-filter
spec:
  configPatches:
    # The first patch adds the lua filter tothe listener/http connection manager
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
       filterChain:
         filter:
           name: envoy.filters.network.http_connection_manager
           subFilter:
              name: envoy.filters.http.router
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.lua
        typed_config:
          "@type":type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
          inline_code: |
            functionenvoy_on_request(request_handle)
              ifrequest_handle:headers():get(":path") == "/xss" then
               request_handle:respond({[":status"] ="403"},"ok")
              end
            end
            functionenvoy_on_response(response_handle)
            end
```

更为完整的采用lua过滤器完成API防护的可以参考开源项目curiefense[5]的实现。

六. 总结

在云原生环境下，利用Service Mesh的架构，在Sidecar提供负载均衡，路由的同时，同时提供API安全防护的能力，可以不仅防护南北向的流量，也可以提供东西向的全流量的安全防护，有效保证的云原生应用的安全性。

参考文献

[1] https://owasp.org/www-project-api-security/

[2] https://istio.io

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

[4] https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/filter/filter

[5] https://www.curiefense.io/

内容编辑：星云实验室 陈建军 责任编辑：高深

所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。