关于阿里云: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 容器架构（图片来自 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 提供一个动态文件代理的路由，从而获取到这个凭证。能够看下有了这个凭证能干什么事件：

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

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

导致破绽的架构根因（图片来自 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 云原生网关的管制面和数据面架构

从上图能够看到，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]。

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

云原生网关插件市场

用户还能够基于 Wasm 技术，用多种语言（Go、JS、Rust 等）实现网关性能动静扩大（无需重启网关），基于 Wasm 的沙箱机制，即便你的代码逻辑拜访了空指针，也不会导致网关 crash。这种平安且简略的扩大机制也是 Ingress Nginx 不具备的。

参考链接：

[1] CVE-2021-25745：