作者：望宸&魁宇
是否還記得 2022 年 K8s Ingress Nginx 披露了的 3 個(gè)高危安全漏洞（CVE-2021-25745, CVE-2021-25746, CVE-2021-25748），并在那一年宣布停止接收新功能 PR，專注修復(fù)并提升穩(wěn)定性。但近期再次被披露 5 個(gè)安全漏洞，攻擊者可利用安全漏洞，接管你的 K8s 集群，被業(yè)內(nèi)稱為 #IngressNightmare 【1】
目錄
01 背景
02 Nginx Ingress 安全漏洞頻出的根因：架構(gòu)設(shè)計(jì)缺陷
03 架構(gòu)設(shè)計(jì)缺陷帶來安全問題，還帶來穩(wěn)定性問題
04 自建網(wǎng)關(guān)容易忽略的細(xì)節(jié)
05 Higress&MSE Ingress：Ingress 的另一種選擇
背景
近日，云安全平臺(tái) Wiz Research 披露了 Ingress Nginx 的 5 個(gè)安全漏洞，分別是 CVE-2025-1097、CVE-2025-1098、CVE-2025-24514 和 CVE-2025-1974，這是 Kubernetes Ingress Nginx Controller 中未經(jīng)身份驗(yàn)證的遠(yuǎn)程代碼執(zhí)行漏洞，這 5 個(gè)安全漏洞的 CVSS v3.1 基本評(píng)分高達(dá) 9.8，被 Wiz 稱為 #IngressNightmare。攻擊者可利用這些漏洞，在未經(jīng)授權(quán)訪問 K8s 集群的情況下，便可獲取所有命名空間中的存儲(chǔ)信息，從而接管 K8s 集群。
CVSS v3.1（Common Vulnerability Scoring System version 3.1，通用漏洞評(píng)分系統(tǒng)3.1版）是用于評(píng)估計(jì)算機(jī)系統(tǒng)安全漏洞嚴(yán)重性的行業(yè)標(biāo)準(zhǔn)框架，由國際組織 FIRST（事件響應(yīng)和安全團(tuán)隊(duì)論壇）維護(hù)。最高分 10 分，分?jǐn)?shù)越高表示漏洞越嚴(yán)重。
漏洞影響范圍與原理
IngressNightmare 的核心問題在于影響了 Kubernetes Ingress Nginx Controller 的準(zhǔn)入控制器組件，據(jù)評(píng)估，約有 43% 的云環(huán)境可能受到這些漏洞的影響。
該漏洞利用了 Kubernetes Pod 中部署的準(zhǔn)入控制器無需認(rèn)證即可通過網(wǎng)絡(luò)訪問的特性。具體來說，攻擊者可以通過直接向準(zhǔn)入控制器發(fā)送惡意 Ingress 對(duì)象（即 AdmissionReview 請(qǐng)求），遠(yuǎn)程注入任意的 Nginx 配置，從而在 Ingress Nginx Controller 的 Pod 上執(zhí)行代碼。
Wiz 解釋道：“準(zhǔn)入控制器的高權(quán)限和無限制的網(wǎng)絡(luò)訪問性創(chuàng)造了一個(gè)關(guān)鍵的提權(quán)路徑。利用此漏洞，攻擊者可以執(zhí)行任意代碼并訪問跨命名空間的所有集群機(jī)密信息，最終可能導(dǎo)致整個(gè)集群被接管。”
漏洞詳情
以下是這些漏洞的具體信息：
CVE-2025-24514– auth-url 注解注入CVE-2025-1097– auth-tls-match-cn 注解注入CVE-2025-1098– mirror UID 注入CVE-2025-1974– Nginx 配置代碼執(zhí)行在實(shí)驗(yàn)性攻擊場(chǎng)景中，威脅行為者可以通過利用 Nginx 的 client-body buffer 功能，將惡意負(fù)載以共享庫的形式上傳到 Pod，然后向準(zhǔn)入控制器發(fā)送 AdmissionReview 請(qǐng)求。該請(qǐng)求包含上述配置指令注入之一，導(dǎo)致共享庫被加載，從而實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行。
修復(fù)建議與緩解措施
目前這些漏洞已在 Ingress NGINX Controller 的 1.12.1、1.11.5 和 1.10.7 版本中得到修復(fù)。建議用戶盡快更新到最新版本，并確保準(zhǔn)入 Webhook 端點(diǎn)不會(huì)對(duì)外暴露。
Nginx Ingress 頻繁爆出安全漏洞的根因：架構(gòu)設(shè)計(jì)缺陷
Ingress Nginx 容器架構(gòu)（圖片來自 kubernetes.io）
Ingress Nginx 安全漏洞頻發(fā)的背后，是由其不安全的架構(gòu)設(shè)計(jì)導(dǎo)致的：將控制面 Ingress Controller 組件（Go 程序），和數(shù)據(jù)面 Nginx 組件放在一個(gè)容器內(nèi)。雖然社區(qū)已經(jīng)將 Nginx 服務(wù)隔離為控制器容器內(nèi)的容器，一定程度較少了一些安全風(fēng)險(xiǎn)，但是無法完全消除?。刂泼婧蛿?shù)據(jù)面依舊在一個(gè)大容器內(nèi)）
控制面扮演了 Admin 的角色，管理很多敏感信息，包括 K8s API Server 通信的認(rèn)證憑證、Nginx 配置文件中的敏感數(shù)據(jù)、集群內(nèi)部服務(wù)的訪問權(quán)限等。數(shù)據(jù)面和控制面共用容器，就會(huì)給攻擊者通過數(shù)據(jù)面獲取這些敏感信息提供了可乘之機(jī)。
以 CVE-2025-1974 的漏洞為例，其根源在于 Ingress Nginx Controller 的準(zhǔn)入控制器（Admission Controller）在處理 AdmissionReview 請(qǐng)求時(shí)存在輸入驗(yàn)證缺陷 ，具體表現(xiàn)為以下兩個(gè)關(guān)鍵點(diǎn)：
惡意指令注入：攻擊者可通過構(gòu)造特殊的 AdmissionReview 請(qǐng)求，向 Nginx 配置中注入 ssl_engine 指令。這一漏洞利用了 Nginx 配置生成過程中的邏輯缺陷，允許攻擊者繞過安全限制，將惡意指令嵌入配置文件。動(dòng)態(tài)庫加載機(jī)制被濫用：結(jié)合 Nginx 的 client-body buffer 功能，攻擊者可將惡意負(fù)載（如共享庫）注入控制器的運(yùn)行時(shí)環(huán)境。當(dāng)控制器執(zhí)行 nginx -t 命令測(cè)試配置時(shí)，會(huì)加載攻擊者指定的惡意庫，從而實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行（RCE）。此外，漏洞的嚴(yán)重性還源于準(zhǔn)入控制器的高權(quán)限與網(wǎng)絡(luò)暴露：
準(zhǔn)入控制器通常擁有集群內(nèi)的高權(quán)限，且若其網(wǎng)絡(luò)暴露，攻擊者可直接利用該漏洞在集群內(nèi)橫向移動(dòng)，訪問所有命名空間的密鑰或執(zhí)行任意代碼。該漏洞無需身份驗(yàn)證即可被利用，進(jìn)一步降低了攻擊門檻。綜上，此漏洞是配置驗(yàn)證缺陷與動(dòng)態(tài)庫加載機(jī)制缺陷的組合，最終允許攻擊者通過注入惡意指令和庫完全接管集群。
架構(gòu)設(shè)計(jì)缺陷帶來安全問題，還帶來穩(wěn)定性問題
運(yùn)維復(fù)雜度高
由于 Nginx Ingress 承擔(dān)了集群的大量入口流量，穩(wěn)定性要求很高，通常情況下，我們會(huì)通過一系列復(fù)雜的配置和運(yùn)維動(dòng)作進(jìn)行保障，例如： 【2】
將其 Pod 獨(dú)立調(diào)度來保證穩(wěn)定性，比如在節(jié)點(diǎn)上設(shè)置污點(diǎn)，并在 Ingress Controller 的 Pod 中設(shè)置污點(diǎn)容忍讓其獨(dú)占節(jié)點(diǎn)資源；為增強(qiáng) Ingress 網(wǎng)關(guān)可靠性，需要結(jié)合業(yè)務(wù)實(shí)際壓力設(shè)置 Ingress 的副本數(shù)和資源分配；出于網(wǎng)關(guān)高峰期彈性考慮，還需要結(jié)合 HPA 以支持網(wǎng)關(guān) Pod 水平擴(kuò)容；Nginx Ingress 實(shí)際是由負(fù)載均衡器提供的對(duì)外訪問能力，還需要結(jié)合業(yè)務(wù)考慮負(fù)載均衡帶寬是否滿足高峰期需求。控制面和數(shù)據(jù)面進(jìn)行資源搶占導(dǎo)致的穩(wěn)定性問題
由于 Nginx 反向代理網(wǎng)關(guān)是部署在 K8s 集群中的，網(wǎng)關(guān)的性能直接受 Pod 資源分配和宿主機(jī)性能影響。且如果 Nginx Ingress Controller Pod 所在的節(jié)點(diǎn)存在其他業(yè)務(wù) Pod，當(dāng)容器 CPU 負(fù)載較高時(shí)，會(huì)出現(xiàn)資源搶占問題，從而引發(fā)穩(wěn)定性風(fēng)險(xiǎn)。
K8s 為 Pod 提供了 livenessProbe 和 readinessProbe 的存活檢查和健康檢查機(jī)制，官方 Nginx Ingress Controller 的 Deployment 部署模版中也使用了該機(jī)制進(jìn)行網(wǎng)關(guān)健康檢查。
其健康檢查和存活檢查使用的是由控制面 Manager 監(jiān)聽的 10254 端口提供的 /healthz 健康檢查入口，而 Nginx Ingress 數(shù)據(jù)面和控制面在同一個(gè)容器中，在業(yè)務(wù)高峰期網(wǎng)關(guān)負(fù)載較高時(shí)，很有可能導(dǎo)致控制面的健康檢查接口響應(yīng)超時(shí)。根據(jù) livenessProbe 機(jī)制，會(huì)引發(fā) Nginx Ingress 網(wǎng)關(guān)不斷重啟導(dǎo)致網(wǎng)關(guān)不穩(wěn)定，流量有損。
此外，控制面 Manager 還負(fù)責(zé)采集 Prometheus 監(jiān)控指標(biāo)，在業(yè)務(wù)高峰期控制面還可能搶占不到足夠的 CPU，出現(xiàn) OOM，導(dǎo)致容器被 Kill 的情況。
以上兩個(gè) issue 雖然已經(jīng)在社區(qū)被 close，但是控制面和數(shù)據(jù)面未分開導(dǎo)致的資源搶占問題，防不勝防。
Nginx 配置更新導(dǎo)致長鏈接掉線
通過 Nginx Ingress 更新 Nginx 網(wǎng)關(guān)路由規(guī)則直接將域名和路徑訂正到 nginx.conf 配置文件，需要更新 Nginx 配置并重新加載才能生效。當(dāng)應(yīng)用存在長連接，如 websocket 的情況下，reload 操作會(huì)導(dǎo)致業(yè)務(wù)連接在一段時(shí)間后出現(xiàn)明顯掉線。
自建網(wǎng)關(guān)容易忽略的細(xì)節(jié)
綜上可見，Nginx Ingress 網(wǎng)關(guān)在 K8s 集群中存在運(yùn)維難度高、數(shù)據(jù)面和控制面未分離導(dǎo)致的資源爭搶、進(jìn)程 reload 長連接有損等短板。當(dāng)我們需要自建 Nginx Controller 時(shí)，設(shè)想一下，在 K8s 中還需要考慮哪些細(xì)節(jié)：
不穩(wěn)定的后端 IP：Pod 的 IP 地址會(huì)隨應(yīng)用的重啟、遷移、新版本發(fā)布頻繁的變更。不穩(wěn)定的后端 IP 讓配置難以下手。頻繁更新的配置文件：每次后端應(yīng)用的變更都需要人工維護(hù) Nginx 配置，當(dāng)構(gòu)建多節(jié)點(diǎn)的高可用 Nginx 服務(wù)時(shí)，需要人工保證多節(jié)點(diǎn)配置的準(zhǔn)確性一致性。配置持久化：由于 Pod 的不穩(wěn)定性，當(dāng)以 Pod 形式部署 Nginx 服務(wù)時(shí)，每次 Pod 的銷毀和新建，在 Pod 中的變更都會(huì)丟失，需要持久化保存配置并掛載到多個(gè) Nginx Pod 中。監(jiān)控面板對(duì)接：需要運(yùn)維人員自行安裝 Nginx 監(jiān)控模塊，并對(duì)接到外部監(jiān)控系統(tǒng)。訪問日志持久化：需要為 Nginx 服務(wù)額外掛載持久化數(shù)據(jù)盤以保存訪問日志。Higress&MSE Ingress：Ingress 的另一種選擇
Higress：內(nèi)核基于 Istio 和 Envoy，采用控制面和數(shù)據(jù)面分離的架構(gòu)，采用 xDS 配置下發(fā) 【3】 ，路由策略生效基于 RDS/ECDS，reload 時(shí)對(duì)長連接完全無影響，并通過 WASM 支持插件的熱更新。從而有效避免本文提到中提到的 Ingress Nginx 安全和穩(wěn)定性問題。MSE Ingress：Higress 的商業(yè)版，提供公共云服務(wù)，在穩(wěn)定性、性能、云產(chǎn)品間的易用性、可觀測(cè)性上更有優(yōu)勢(shì)。接下來，我們以 MSE Ingress 為例，將 Nginx Ingress 和 MSE Ingress 做一個(gè)全面的比對(duì)。
MSE Ingress 由 MSE Ingress Controller 和 MSE 云原生網(wǎng)關(guān)構(gòu)成，其中 MSE 云原生網(wǎng)關(guān)采用分離架構(gòu)。
MSE Ingress Controller： 不是網(wǎng)絡(luò)數(shù)據(jù)平面，它是管理 MSE 云原生網(wǎng)關(guān)實(shí)例以及配置的控制平面。即 MSE Ingress Controller 不處理任何業(yè)務(wù)請(qǐng)求流量，它位于流量旁路，管理著處理業(yè)務(wù)流量的 MSE 云原生網(wǎng)關(guān)實(shí)例。MSE 云原生網(wǎng)關(guān)： MSE 云原生網(wǎng)關(guān)由 MSE Ingress Controller 根據(jù)用戶配置的 MseIngressConfig 資源創(chuàng)建，包含控制面和數(shù)據(jù)面。
控制面：監(jiān)聽您已關(guān)聯(lián)的容器服務(wù)集群中的 Ingress、IngressClass、Service 等資源，經(jīng)內(nèi)部解析之后實(shí)時(shí)下發(fā)給網(wǎng)關(guān)數(shù)據(jù)面。數(shù)據(jù)面：數(shù)據(jù)面是流量治理配置的實(shí)施者，按照控制面下發(fā)的治理規(guī)則處理外部請(qǐng)求，并轉(zhuǎn)發(fā)到后端目標(biāo)服務(wù)。
MSE Ingress Controller 負(fù)責(zé)監(jiān)聽集群中的 MseIngressConfig 資源，協(xié)調(diào) MSE 云原生網(wǎng)關(guān)實(shí)例用于實(shí)施Ingress 資源描述的流量管理規(guī)則。與 Nginx Ingress Controller 不同，MSE Ingress Controller 是管理 MSE 云原生網(wǎng)關(guān)實(shí)例以及配置的控制面，MSE Ingress Controller Pod 不直接處理用戶請(qǐng)求流量，用戶流量的路由和轉(zhuǎn)發(fā)由 MSE 云原生網(wǎng)關(guān)實(shí)例來實(shí)現(xiàn)。
【1】#IngressNightmare：
https://thehackernews.com/2025/03/critical-ingress-nginx-cont...
【2】《Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication》：
https://mp.weixin.qq.com/s/rXND432WjsQCErESNjcu5g
【3】《Ingress Nginx 接連披露高危安全漏洞，是否有更好的選擇？》：
https://mp.weixin.qq.com/s/WCWVHUo3UxcckBriKOlKeQ
