先给结论：如果你集群的入口还在跑社区版 ingress-nginx，那你现在要面对的不是"要不要升级"，是"这东西已经没人修了"。
K8s 社区的 ingress-nginx controller，2026 年 3 月正式退役。退役本身不吓人，吓人的是它退役之后爆出来的那一串洞——以配置注入为主，而 EOL 分支没有上游补丁。
随手列几个能查到出处的：
- CVE-2026-24512，
rules.http.paths.path的 nginx 配置注入，CVSS 8.8。能 RCE，而且能把 controller 权限范围内能碰到的所有 K8s Secret 一并读走。 - CVE-2026-1580（auth-method 注入）、CVE-2026-3288（rewrite-target 注入）、CVE-2026-4342（注释型注入）、CVE-2025-15566（auth-proxy-set-headers 注入）——都是同一类毛病：往注解里塞点东西，最后被拼进 nginx 配置里执行。
- CVE-2026-24513 是 auth-url 的保护绕过；CVE-2026-24514 是 Admission Controller 的拒绝服务。
- 还有一条更硬的：CVE-2026-42533，F5 在 2026 年 7 月披露的 NGINX 堆溢出，不需要认证，一个普通 HTTP 请求就能触发，EOL 的 1.15.1 里没有修复。
这些不是小道消息，Kubernetes 官方 CVE feed 里能一条条对到。
我说这轮比一般的"组件高危洞"更难受，是因为入口组件的洞，性质跟别的组件不一样。ingress 就站在集群门口，谁有权限创建或者修改 Ingress 资源，谁就能拿这些注入点去打它。而它借的是 controller 手上那份权限——controller 通常攥着一大把 Secret。一个注入点，可能直接换出一整套凭据，后面还牵连多少下游，取决于你平时把权限撒得多开。
这一点我算是有点体感。我们内部那套七亿批量远程管理工具，管的是成片的 Windows 机器的 RDP/SSH 这一层，说起来也算个"入口类组件"——它手里握着所有被管机器的连接凭据，一旦被拿下，就是整片机器跟着塌。所以后来我把它的权限收得很死：工具自己能做什么、不能做什么，尽量按最小权限去切，宁可麻烦点。入口类的组件就是这样，权限给得越顺手，出事时塌得越彻底。这些取舍当时在我们的使用教程里也写过几句（批量远程工具的上手教程）。
那到底该怎么自检？我自己会先问这四个问题：
- 集群里的 ingress 是社区版，还是云厂商停更前那个分支？版本号具体是多少？停在 1.15.1 这类 EOL 分支的，就是没有补丁可打。
- 谁能创建、修改 Ingress？如果开发同学人手一个权限，那你的攻击面就是整个组。
- controller 的 RBAC 能不能读全集群的 Secret？能的话，一个注入点就等于一次全量泄漏。
- 有没有 Falco 这类东西在盯 k8s_audit？Sysdig 针对 CVE-2026-3288 / 24512 出过检测规则，能先顶一阵，至少比裸奔强。
修补方向，社区现在的共识是往 Gateway API / Traefik 迁。IBM Cloud、Nutanix、OVHcloud、SUSE、TIBCO 这几家已经把 Traefik 当成战略 ingress 方案了，KubeCon EU 2026 上直接把它称作事实标准。我倒不是说 Traefik 一定最好，而是"一个还有人维护、还有人接漏洞"的组件，总比一个已经退役的强。之前我为了防爆破，还给入口那层加过一层按归属地的白名单，思路是一样的：入口这东西，能多一层收敛就多一层。
说白了就一句：能用，不等于有人在管。
平时我们盘资产，眼睛都盯着"这台机器什么时候到期""那张证书哪天续"，反而容易漏掉一栏——"这个组件，还有没有人在维护"。等出事再回头查，查到的往往就是：它早就不在维护名单里了。我写这篇的时候顺手把手上几台机器的中间件捋了一遍，有些东西，不盘不知道，一盘有点心惊。
评论