Ingress Nginx 接连披露高危安全漏洞，是否有更好的选择？

作者： 澄潭

今年 K8s Ingress Nginx 项目接连披露了三个高危安全漏洞（CVE-2021-25745 [ 1] , CVE-2021-25746 [ 2] , CVE-2021-25748 [ 3] ），该项目也在近期宣布将停止接收新功能 PR，专注修复并提升稳定性。Ingress Nginx 作为 K8s 项目自带的网关组件，被大量用户的 K8s 集群默认安装。作为处于 Internet 网络边界的基础软件，又被大规模使用，势必会成为一些攻击者的理想目标。一旦防线攻破，其代价是惨痛的，可以参考同样是网络边界的基础组件，OpenSSL 的 Heartbleed 心血漏洞殷鉴不远。

2014 年 Heartbleed 漏洞释出不久，OpenBSD 开始自行维护 LibreSSL，Google 也推出了 BoringSSL，基于和 OpenSSL 遵循同一套 SSL/TLS 协议标准，提供更安全的替代品。类似的，基于同一套 K8s Ingress API 标准，是否有更安全的 K8s 网关可以替代 Ingress Nginx？

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-example
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: bar.foo.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80

Ingress API 标准示例

在《K8s 网关选型初判：Nginx 还是 Envoy》一文中，我们已经给出了这个新的选项：MSE 云原生网关。本文继续展开分析，为何 MSE 云原生网关有更好的安全性保障。

Ingress Nginx 架构设计缺陷

title=

Ingress Nginx 容器架构（图片来自 kubernetes.io）

Ingress Nginx 安全漏洞频发的背后，是由其不安全的架构设计导致的：将控制面 Ingress Controller 组件（Go 程序），和数据面 Nginx 组件放在一个容器内。控制面在这里是一个 Admin 的角色，可想而知其会管理一些敏感的信息，例如和 K8s API Server 通信的认证凭证。数据面和控制面共用容器，就给攻击者通过数据面获取这些敏感信息提供了可乘之机。举例来说：

K8s 使用了 RBAC 机制实现 API Server 接口的认证鉴权，而用于 RBAC 认证的凭证信息，会通过 volume 挂载到容器的/var/ru n/secrets/kubernetes.io/serviceaccount 目录。CVE-2021-25745 就是利用了控制面拼接 nginx.conf 配置文件的漏洞，通过 Ingress Path 实现了配置注入，让 Nginx 提供一个静态文件代理的路由，从而获取到这个凭证。可以看下有了这个凭证能干什么事情：

title=

Ingress Nginx 凭证权限（图片来自 blog.lightspin.io）

上图是 ingress-nginx 这个 ServiceAccount 角色的 ClusterRole 权限描述，因为网关需要加载 TLS 证书，所以这个角色是具有查看集群内所有 Secret 的权限的。攻击者不但能通过这个凭证拿到所有 TLS 证书的私钥信息，还能拿到集群里所有密钥类配置！

title=

导致漏洞的架构根因（图片来自 blog.lightspin.io）

实际上，CVE-2021-25746 和 CVE-2021-25748，包括更早的 CVE-2021-25742 [ 4] ，根因都是这个问题。CVE-2021-25742 基于 custom snippet 通过 Nginx 配置片段实现凭证获取；CVE-2021-25746 可以基于多种 Ingress Annotation 实现 Nginx 配置片段注入获取凭证；CVE-2021-25748 绕过了针对 CVE-2021-25745 修复的正则检测。真是防不胜防......

Ingress Nginx 社区认识到了这个架构问题的严重性，已经开始计划做控制面和数据面的分离。若继续保持现有架构，未来可能会爆出更严重的安全漏洞。

值得注意的是，这种架构除了会导致上述安全问题，还会导致容器 CPU 负载较高时，控制面和数据面进程互相抢占调度，出现一系列稳定性问题，例如：

由控制面负责的存活健康检查（livenessProbe）超时失败，导致容器不断重启
在开启了 prometheus 采集监控指标的情况下，控制面因为高负载抢占不到足够的 CPU，会出现 OOM，导致容器被 kill，详细原因见文末相关 issue [ 5]

更安全的替代品——MSE 云原生网关

title=

MSE 云原生网关的控制面和数据面架构

从上图可以看到，MSE 云原生网关使用了数据面（Envoy）和控制面（Istio）隔离的架构，从根本上避免了上述问题。MSE 云原生网关采用了托管部署的模式，不是部署在用户自己的 K8s 集群中，即使出现了安全漏洞，用户也可以通过一键平滑升级轻松修复漏洞。并且有专业安全团队收集漏洞情报，相比开源能提供更迅速、更可靠的修复方案。

基于前面几个 CVE 漏洞原理的说明，不难发现 Ingress Nginx 通过控制面拼接 nginx.conf 配置实现数据面控制的方式也存在很大的安全隐患，例如定义一个特殊的 Ingress Path：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-example
spec:
  rules:
  - http:
      paths:
      - pathType: Prefix
        # 下文中{...}省略号隐去了可能引发漏洞的配置
        path: "/inject{...}location /abc"
        backend:
          service:
            name: service
            port:
              number: 80

就会在生成的 nginx.conf 中出现如下配置片段：

location /inject{...}location /abc {
  set $ingress_name "ingress-example";
  ...
  ...
}

熟悉 Nginx 配置的同学会了解，这里有两个 location 路径匹配规则，其中 location /abc 是对应上述 Ingress 路由配置的，而 location /inject 则可以实现一个额外的配置注入，在{...}中可以写任意的 Nginx Location 级别配置，甚至使用灵活度很高的 Lua 脚本，达到配置注入者的各种目的。

不同于 Ingress Nginx 通过控制面拼接 nginx.conf 配置实现数据面控制，云原生网关使用了更安全可靠的 xDS 协议，通过 xDS API 配置解析替代字符串拼接，从根本上避免了拼接配置导致配置注入的问题，确保配置动作是明确的，行为是可预期的。下面是向 Envoy 下发路由匹配规则用到的 proto 协议，不同于 Ingress Nginx 的 location 指令拼接，这种方式显然约束了路由匹配配置的作用范围。

message RouteMatch {
  option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.route.RouteMatch";
  message GrpcRouteMatchOptions {
    option (udpa.annotations.versioning).previous_message_type =
        "envoy.api.v2.route.RouteMatch.GrpcRouteMatchOptions";
  }
  message TlsContextMatchOptions {
    option (udpa.annotations.versioning).previous_message_type =
        "envoy.api.v2.route.RouteMatch.TlsContextMatchOptions";
    google.protobuf.BoolValue presented = 1;
    google.protobuf.BoolValue validated = 2;
  }
  // An extensible message for matching CONNECT requests.
  message ConnectMatcher {
  }
  reserved 5, 3;
  reserved "regex";
  oneof path_specifier {
    option (validate.required) = true;
    string prefix = 1;
    string path = 2;
    type.matcher.v3.RegexMatcher safe_regex = 10 [(validate.rules).message = {required: true}];
    ConnectMatcher connect_matcher = 12;
    string path_separated_prefix = 14 [(validate.rules).string = {pattern: "^[^?#]+[^?#/]$"}];
    string path_template = 15
        [(validate.rules).string = {min_len: 1 max_len: 256 ignore_empty: true}];
  }
  google.protobuf.BoolValue case_sensitive = 4;
  core.v3.RuntimeFractionalPercent runtime_fraction = 9;
  repeated HeaderMatcher headers = 6;
  repeated QueryParameterMatcher query_parameters = 7;
  GrpcRouteMatchOptions grpc = 8;
  TlsContextMatchOptions tls_context = 11;
  repeated type.matcher.v3.MetadataMatcher dynamic_metadata = 13;
}

值得一提的是，目前 Ingress Nginx 的大量路由策略功能都需要通过更新 nginx.conf，然后重启 Nginx 生效，重启过程中客户端连接会断开，在 websocket 等长连接场景下，会造成业务影响；而通过 Envoy 的 xDS 配置下发，路由策略生效基于 RDS/ECDS，对长连接完全无影响。

为了方便用户从 Ingress Nginx 平滑迁移到 MSE 云原生网关，我们除了完全兼容了 K8s Ingress API 的标准，也兼容了常用的 Ingress Nginx Annotation，详见文末文档 [ 6] 。

此外，云原生网关的插件市场提供了多种认证鉴权和安全防护插件，可以增强网络安全防护能力：

title=