一、漏洞描述
在Kubernetes中，服务和Pod的IP地址仅可以在集群网络内部使用，对于集群外的应用是不可见的。
为了使外部的应用能够访问集群内的服务，其中就可采用ingress 方案：ingress controller+ingress服务；Kubernetes Ingress NGINX Controller (Apache License 2.0) 是一个基于 NGINX 的 Ingress 控制器，用于管理 Kubernetes 集群中服务的外部访问。它负责解析 Ingress 资源定义的反向代理规则，并将外部流量路由到集群内的服务（Service）上。ingress controller通过和kubernetes api交互，动态的去感知集群中ingress规则变化，然后读取它，按照自定义的规则：写明了哪个域名对应哪个service，生成一段nginx配置，再写到nginx-ingress-control的pod里，这个Ingress controller的pod里运行着一个Nginx服务，控制器会把生成的nginx配置写入/etc/nginx.conf文件中，然后reload一下使配置生效。以此达到域名分配和动态更新的目的。Ingress NGINX Controller是能将Nginx网站平台作为Kubernetes环境输入控制器；
- 流量路由和负载均衡：Nginx Ingress Controller 将外部流量路由到集群内的服务，并提供负载均衡功能，确保流量分配均匀；在同一个 Kubernetes 集群中，为不同用户或环境部署多个 Ingress Controller，以隔离流量和配置；当需要根据不同的 Host、URL 路径等规则将流量路由到不同的服务时，Nginx Ingress Controller 可处理负载路由；
- 单一入口点：为多个服务提供一个统一的入口点，缩小暴露面
- SSL/TLS 转化：支持 HTTPS 协议，实现 SSL/TLS 最终转化，提高安全性
- 访问控制和限速：可以配置访问控制策略和限速规则，提高灵活性；在需要处理大量流量的场景下，通过优化 Nginx Ingress Controller 的配置来提高性能
- 灰度发布和蓝绿发布：利用 Ingress Controller 实现灰度发布和蓝绿发布，方便应用版本更新和回滚
Ingress NGINX Controller 远程代码执行漏洞，是ingress-nginx会在Pod其中部署访问控制器，针对所传入的对象会进行验证，通过后才会放行、部署；然而在默认组态其中Ingress NGINX Controller 的准入控制器在处理 Ingress 对象时，用户无需通过身份验证，即可通过网络连接访问控制器，这很有可能变成攻击的渠道，即过程未对用户输入进行充分验证和清理。攻击者通过向准入控制器发送恶意的 AdmissionReview请求，注入任意 NGINX 配置指令，并在配置验证阶段（使用 nginx -t）触发代码执行。导致攻击者可访问所有命名空间中的密钥数据，包括用户凭据和访问令牌，以及在Ingress NGINX Controller 的 Pod 上执行任意代码，因其是高权限角色，一旦遭到利用，攻击者就有机会在未经授权的情况下访问Kubernetes集群，挖掘所有命名空间（namespace）其中的全部机密数据，导致k8s集群完全失控被远程接管利用。相关安全研究人员评估：全球约有43%云计算环境存在相关弱点，超过6,500个集群曝险，包含财富500大的企业，因此影响可能会相当广泛，建议用户应尽快修补。
漏洞编号： CVE-2025-1097、CVE-2025-1098、CVE-2025-24514 和 CVE-2025-1974
危险等级： 重大，CVSS风险评为 9.8
影响版本：Ingress NGINX Controller < 1.11.5，Ingress NGINX Controller < 1.12.1
相关资源：ingress-nginx、ingress、/ingress-nginx发布说明、Nginx升级、部署指导、官方文档、Kubernetes 包管理器 Helm、Helm 入门指南
二、处理
官方已发布修复补丁，请升级至最新版本或Ingress NGINX Controller 1.12.1；如果暂时无法升级，可以临时限制准入控制器仅允许 Kubernetes API 服务器访问。
1）升级
由于 Nginx Controller 各个版本支持的 Kubernetes 版本范围比较窄，可通过新建实例来实现过渡这种方案来升级 Nginx Controller。
//1、安装新版本 Nginx Controller 实例
#https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.12.1
#wget https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.12.1
git clone https://github.com/rancher/ingress-nginx.git && cd ingress-nginx
# 进入你使用的controller版本分支
git checkout nginx-1.12.1-rancher2
cd images/nginx/rootfs
vi build.sh #修改构建脚本
docker build -t nginx-base-image:v1.12.1 .
make image ARCH=amd64
#方式2：Helm 用于 Kubernetes 应用程序 Chart 的创建、打包、发布以及创建和管理本地和远程的 Chart 仓库；Helm Chart 是Helm 的软件包，采用 TAR 格式，类似于 APT 的 DEB 包或者 YUM 的 RPM 包，其内部封装了 Kubernetes 原生应用程序的一系列 YAML 文件。可以在你部署应用的时候自定义应用程序的一些 Metadata；
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.1/deploy/static/provider/cloud/deploy.yaml
#或：修改deployment的yaml文件的image就行，k8s会自动拉取新的镜像启动容器
kubectl get svc --all-namespaces
kubectl set image deployment/nginx-ingress-controller nginx-ingress-controller=quay.io/kubernetes-ingress-controller/nginx-ingress-controller:1.12.1 -n kube-system
#验证：kubectl get pods -n <namespace-of-ingress-controller>
kubectl get pod -A #查看新的容器状态
#kubectl describe ing <ingress-resource-name> -n <namespace-of-ingress-resource>
kubectl describe pod nginx-ingress-controller-xxx -n kube-system
kubectl logs -n <namespace> ingress-nginx-controller-xxx
#查看Nginx配置
kubectl exec -it -n <namespace-of-ingress-controller> ingress-nginx-controller-xxx -- cat /etc/nginx/nginx.conf
//2、迁移 Ingress 资源，将所有旧 Nginx Controller 相关资源复制到新实例中。迁移时新实例中请保留原有 Ingress 不变，复制一个新的 Ingress 实例。请确保实例名称不能出现冲突。将新实例的 kubernetes.io/ingress.class修改为原实例名称一致；
//3、测试、流量切换 或回滚
#修改DNS映射：测试通过之后，更新 DNS 解析至新的 IP，以验证新的入口访问是否正常
//4、清理旧实例
#在全部流量迁移至新实例之后，先清理旧 Nginx Ingress 实例相关的 Ingress 资源，完成后再销毁 Nginx Ingress 旧实例
