IngressNightmare (CVE-2025-1974)：漏洞详解与 Gateway API 迁移指南

Shengxu included in Kubernetes Security News

2025-12-27 About 600 words 3 minutes

Contents

最近曝光的 Ingress-NGINX “IngressNightmare” 漏洞，把 nginx‑ingress 再次推上风口浪尖，也给还停留在传统 Ingress 的集群敲了警钟。

下面从漏洞回顾、风险分析、短期修补，到如何借机迁移到 Gateway API，以及迁移前后的优劣对比，做一篇面向工程实践的技术梳理。

漏洞简要回顾：IngressNightmare（CVE‑2025‑1974）

严重程度：2025 年 3 月，研究者披露了 Ingress‑NGINX 控制器中的一组高危漏洞，统称 “IngressNightmare”。其中 CVE‑2025‑1974 CVSS 评分高达 9.8，被官方和多家安全厂商评为“严重”，影响大量 Kubernetes 集群。
漏洞原理：核心问题在于 Validating Admission Webhook。在验证 Ingress 对象时，控制器会根据对象和注解生成一份 NGINX 配置，并使用 nginx -t 进行校验。这个过程中对注解和配置片段的过滤不足，允许攻击者注入任意 NGINX 指令，最终导致在控制器 Pod 上执行任意代码（RCE）。
攻击门槛低：只要攻击者能访问 Pod 网络中的 admission webhook（很多集群甚至将其暴露在公网），就可以通过未认证请求触发漏洞。这属于 未认证 RCE，极易被蠕虫或自动化攻击工具批量利用。
漏洞链：同一批披露中还包含数个高危注入类漏洞（如 CVE‑2025‑24514、CVE‑2025‑1097、CVE‑2025‑1098），整体被称为 IngressNightmare 漏洞链，攻击面远不止单一 CVE。

风险与影响：从 NGINX 到整个集群的接管

敏感信息泄露：一旦在 ingress‑nginx 控制器容器内获得 RCE，攻击者可以读取挂载到该 Pod 的所有 Kubernetes Secret。特别需要注意的是，NGINX Ingress Controller 通常拥有极高的权限（ClusterRole），需要读取集群中所有命名空间的 Secret 以获取 TLS 证书。这意味着 RCE 的后果不仅是当前 Namespace，而是全集群证书与凭据的彻底泄露。
流量劫持与篡改：控制器通常拥有对集群 Ingress 资源的读写权限。结合 RCE，攻击者能进一步篡改路由，把用户流量透明转发到攻击者控制的后端，实施中间人攻击或数据窃取。
“一洞穿云”：多家安全厂商实测表明，在默认网络策略较宽松的集群中，攻击者只需拿到任意 Pod 的执行权限，即可横向访问 admission webhook，从而升级为集群级别的控制权。

短期止血方案：先补洞，再谈重构

在讨论 Gateway API 迁移之前，所有还在跑 ingress‑nginx 的集群需要立即做两件事：

1. 升级到修复版本

官方和多家安全分析建议将 ingress‑nginx 升级到 v1.11.5 或 v1.12.1 及以上版本（对应 Helm chart 4.11.5 / 4.12.1 及以上）。这些版本已经合入了针对 IngressNightmare 系列漏洞的补丁。
对于托管环境（如 EKS Add‑on、AKS Ingress、GKE Ingress 等），需参照云厂商公告，选择包含修复的控制器版本或集群补丁。很多安全公告都强调应将修复视为“紧急变更”而非普通维护窗口任务。

2. 收紧 Admission Webhook 暴露面

无论是否升级，确保 Validating Admission Webhook 不对公网开放。
在集群内，通过 NetworkPolicy 或安全组限制仅 API Server 能访问该服务，这是官方和安全厂商一致的建议。
在部分场景下，如果暂时无法升级，可 临时禁用 ingress‑nginx 的验证 Webhook 功能，只依赖静态配置生成，但要权衡丢失校验带来的配置错误风险。
建议接入专门的漏洞扫描或规则（WAF / IDS / NIDS），检测针对 admission webhook 的异常流量和恶意 Ingress 对象（如利用特定注解 payload）。

借机重构：为什么要从 Ingress 迁移到 Gateway API？

虽然打补丁可以缓解当前漏洞，但 IngressNightmare 暴露了 Ingress + 注解 这种模式的长期结构性问题：

语义混乱：路由、TLS、L7 策略等都被塞进一个 Ingress 对象和若干 implementation‑specific 注解里，语义不清晰、很难进行静态验证，也不利于安全团队建立统一基线。
厂商锁定：各家 Ingress 控制器的行为差异很大，注解名和语义都不统一，迁移成本高、安全分析也困难。

Gateway API 则是社区给出的“下一代入口标准”，具备几个关键优势：

第一类公民的 CRD 模型：通过 GatewayClass、Gateway、HTTPRoute/TCPRoute/GRPCRoute 等资源把“入口网关”和“路由规则”解耦，更接近 Service Mesh / API Gateway 的思维模型。
角色清晰：平台团队管理 GatewayClass/Gateway，业务团队只需要关心 HTTPRoute 等路由对象，便于安全和运维分责。
实现多样：目前已有 NGINX Gateway Fabric、Envoy Gateway、Istio、Kong、GKE Gateway 等多种实现，都围绕同一套 Gateway API 规范演进，可以按需要选择或更换实现。
天然支持更复杂场景：例如多 Listener、基于 SNI / Host / Path 的多层匹配、流量拆分、限流、WAF 等，在模型上比 Ingress 直观且标准。

从安全角度看，Gateway API 把“配置注入”的能力从注解中抽离到更结构化的字段与策略对象上，有利于 Admission Controller 做精细校验和策略验证，从根源降低类似 IngressNightmare 这类“配置注入”漏洞的爆炸半径。

迁移思路：从 nginx‑ingress 到 Gateway API

一个相对安全、可控的迁移路径通常包括以下步骤（可在预生产或蓝绿环境演练）：

步骤 1：盘点现有 Ingress 与依赖

导出当前集群所有 Ingress YAML，梳理 host、path、后端 Service、TLS Secret 等关键字段，标记使用了大量 NGINX 注解的“深度绑定”场景。
找出所有依赖 ingress‑nginx 特有功能的地方（如自定义 nginx.ingress.kubernetes.io/* 注解），评估能否用 Gateway API 的标准能力或目标控制器的扩展字段替代。

步骤 2：选择 Gateway API 实现

如果你希望继续使用 NGINX 生态，可选择 NGINX Gateway Fabric 这类基于 Gateway API 的实现。
如果更偏向 Envoy/Istio，可使用 Envoy Gateway 或 Istio 的 Gateway API 支持。
云厂商也有各自托管实现（如 GKE Gateway、AWS VPC Lattice + Gateway API 集成等）。
关键点：控制面改为 Gateway API，数据面可自由选择 NGINX / Envoy / 云网关，避免再次被某个 Ingress 实现锁死。

步骤 3：把 Ingress 规则映射为 Gateway + HTTPRoute

典型映射方式：
- Ingress host, paths → Gateway Listener + HTTPRoute hostnames / rules.matches
Gateway 负责监听端口、协议和 TLS 终止；HTTPRoute 承担路径和 Header 等 L7 匹配，以及后端 Service 选择和权重分流。
可使用诸如 ingress2gateway 一类的工具自动转换基础字段，再手动补充高级能力（流量治理、重试、超时等）。

步骤 4：双栈运行与流量切换

在同一集群中同时保留原有 Ingress 和新的 Gateway/HTTPRoute，复用同一个 TLS Secret，使两套入口都能正常处理流量，便于 A/B 对比与回滚。
通过 DNS 或负载均衡配置逐步将流量切到 Gateway，一开始可以只迁移部分域名或路径，验证观测性、日志、安全策略是否满足要求。

步骤 5：下线 ingress‑nginx 控制器

当所有 Ingress 规则被 Gateway API 替代，并经过一段时间的稳定运行后，就可以逐步删除旧的 Ingress 资源，并最终下线 ingress‑nginx 控制器部署。
注意：在此之前，仍需保持 ingress‑nginx 升级至修复版本，以防尚未迁移的业务暴露在已知漏洞下。

迁移前后对比：安全性与运维体验

能力与治理对比

维度	迁移前：nginx‑ingress + Ingress	迁移后：Gateway API + 现代实现
配置模型	单一 Ingress + 注解，语义分散，强依赖实现细节	Gateway / HTTPRoute / Policy 等结构化 CRD，语义清晰、易于验证。
安全面	注解可注入 NGINX 配置，Admission 容易犯错；IngressNightmare 暴露设计缺陷	校验粒度更细，策略对象独立，便于 Admission / Policy 控制，降低配置注入风险。
实现选择	主要绑定 ingress‑nginx 或少数控制器	多家实现共享同一 API，Nginx / Envoy / Istio / 云厂商可互换。
运维分工	平台与业务共用 Ingress 对象，权限边界模糊	平台管 GatewayClass/Gateway，业务管 Route，更适合大规模组织。
迁移成本	与现有 Ingress 实现高度耦合，迁移困难	后续更换数据面基本只需切换 GatewayClass，实现“控制面稳定，数据面可插拔”。

实际感受（站在工程视角）

短期：打补丁 + 收紧 Webhook 暴露，可以迅速把风险从“0day 爆炸”降到“可控缺陷”，这一步必须立即做。
中期：在已有 Ingress 之上硬补更多安全策略、WAF、审计规则，会越来越像在技术债上“贴膏药”。
长期：把控制面迁到 Gateway API，把 NGINX/Envoy 等实现当作“可更换的数据平面”，才是真正降低未来类似 IngressNightmare 类事件冲击面的方式。

写在最后

IngressNightmare 不是“nginx‑ingress 写得太差”，而是 Ingress + 注解 这条路线在复杂、安全敏感的生产环境里，已经走到了架构极限。

对还在大量使用 nginx‑ingress 的团队，比较务实的路线是：

立刻补洞：升级到修复版本，封闭 Webhook，接入扫描与告警。
中期演练：在预生产环境设计并验证 Gateway API 方案。
长期规划：新业务优先走 Gateway API，存量 Ingress 分批迁移，逐步下线 ingress‑nginx。

这样既能对当下的高危漏洞做出快速响应，又能把这次安全危机变成一次网络架构现代化的契机。