*作者：* *澄潭*

今年 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》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247527208&idx=1&sn=e10e524f2bbd5c3f20db0544f2cf9a05&chksm=fae660e7cd91e9f110938be2e9555addc87c9b8b6d9b8217a14a9b5cbd4edf29238555e1873d&scene=21#wechat_redirect)一文中，我們已經給出了這個新的選項：MSE 雲原生閘道器。本文繼續展開分析，為何 MSE 雲原生閘道器有更好的安全性保障。

## Ingress Nginx 架構設計缺陷

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b5089dcc981549958409b9184595d103~tplv-k3u1fbpfcp-zoom-1.image "1.png")

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 提供一個靜態檔案代理的路由，從而獲取到這個憑證。可以看下有了這個憑證能幹什麼事情：

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5bce05dd420847d98cdb012ccf0615e5~tplv-k3u1fbpfcp-zoom-1.image "2.png")

Ingress Nginx 憑證許可權（圖片來自 blog.lightspin.io）

上圖是 ingress-nginx 這個 ServiceAccount 角色的 ClusterRole 許可權描述，因為閘道器需要載入 TLS 證書，所以這個角色是具有檢視叢集內所有 Secret 的許可權的。攻擊者不但能透過這個憑證拿到所有 TLS 證書的私鑰資訊，還能拿到叢集裡所有金鑰類配置！

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3b313408946c4a4ab90ebeb63967d462~tplv-k3u1fbpfcp-zoom-1.image "3.png")

導致漏洞的架構根因 （圖片來自 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 負載較高時，控制面和資料面程式互相搶佔排程，出現一系列穩定性問題，例如：

1. 由控制面負責的存活健康檢查（livenessProbe）超時失敗，導致容器不斷重啟

2. 在開啟了 prometheus 採集監控指標的情況下，控制面因為高負載搶佔不到足夠的 CPU，會出現 OOM，導致容器被 kill，詳細原因見文末相關 issue **[** **5]**

## 更安全的替代品——MSE 雲原生閘道器

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ef7bf263b429421a8169af3a9db44e86~tplv-k3u1fbpfcp-zoom-1.image "4.png")

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]** 。

此外，雲原生閘道器的外掛市場提供了多種認證鑑權和安全防護外掛，可以增強網路安全防護能力：

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/881b85b860b3408db9469ddded4c6d7f~tplv-k3u1fbpfcp-zoom-1.image "5.png")

雲原生閘道器外掛市場

使用者還可以基於 Wasm 技術，用多種語言（Go、JS、Rust 等）實現閘道器功能動態擴充套件（無需重啟閘道器），基於 Wasm 的沙箱機制，即使你的程式碼邏輯訪問了空指標，也不會導致閘道器 crash。這種安全且簡單的擴充套件機制也是 Ingress Nginx 不具備的。

***參考連結：***

*[1] CVE-2021-25745：*

*<https:>*

*[2] CVE-2021-25746：*

*<https:>*

*[3] CVE-2021-25748：*

*<https:>*

*[4] CVE-2021-25742：*

*<https:>*

*[5] 相關 issue：*

*<https:>*

*[6] 文件：*

*<https:>*</https:></https:></https:></https:></https:></https:>

Ingress Nginx 接連披露高危安全漏洞，是否有更好的選擇？

相關文章