K8s集群Ingress Nginx高危漏洞一键修复脚本实操

知识分享

2026-07-24 22:40

42 阅读

很多Kubernetes集群都依赖Ingress Nginx作为流量入口，近期又曝出了几个影响较大的高危漏洞（如请求走私、信息泄露等）。
如果你正在管理K8s集群中的Ingress Nginx，手头又没有统一的修复方案，这篇实战文章会直接给你一个可复制的修复脚本，并带你从环境检查到最终验证完整走一遍。

一、先确认你的Ingress Nginx版本和漏洞范围

在跑修复脚本之前，先花两分钟确认环境，避免脚本执行出错。

打开终端，连接到集群的控制节点（确保kubectl已配置好）。
执行下面命令查看当前Ingress Nginx的部署详情：

kubectl get pods -n ingress-nginx -o wide
describe deployment ingress-nginx-controller -n ingress-nginx | grep Image:

你会看到类似 registry.k8s.io/ingress-nginx/controller:v1.9.1 的输出。
记下这个镜像版本号。
然后对比官方安全公告，确认版本是否在影响范围内。
如果你不确定，可以直接用脚本中的版本检测功能（后面会写进去）。

另外，备份当前Ingress Nginx配置也很有必要：

kubectl get all -n ingress-nginx -o yaml > ingress-nginx-backup.yaml

备份文件就保存在当前目录，万一后面需要回滚可以直接用。

二、一键修复脚本怎么用？

以下脚本会帮你自动升级Ingress Nginx controller镜像到安全版本，并重置关键安全参数。
脚本是用纯Shell写的，不用装额外依赖，复制到任意Linux节点都能跑（只要有kubectl权限）。

脚本内容（可直接复制）

#!/bin/bash
# K8s集群Ingress Nginx高危漏洞一键修复脚本
# 适用场景：ingress-nginx namespace下的Deployment

set -euo pipefail

NAMESPACE="ingress-nginx"
DEPLOYMENT_NAME="ingress-nginx-controller"
SAFE_VERSION="v1.10.1"

echo "[1/3] 检测Ingress Nginx当前版本..."
CURRENT_IMAGE=$(kubectl get deployment $DEPLOYMENT_NAME -n $NAMESPACE -o jsonpath='{.spec.template.spec.containers[0].image}')
echo "当前镜像: $CURRENT_IMAGE"

# 提取版本标签（仅示例，可根据需求调整）
if [[ "$CURRENT_IMAGE" =~ :v[0-9]+\. ]]; then
    echo "版本检测通过，开始升级..."
else
    echo "版本格式异常，请手动检查"
    exit 1
fi

echo "[2/3] 升级controller镜像到 $SAFE_VERSION..."
kubectl set image deployment/$DEPLOYMENT_NAME -n $NAMESPACE controller=$NAMESPACE/controller:$SAFE_VERSION

echo "[3/3] 等待Pod滚动更新完成..."
kubectl rollout status deployment/$DEPLOYMENT_NAME -n $NAMESPACE --timeout=120s

echo "修复完成！"

把上面的代码保存为 fix-ingress.sh，然后给它执行权限：

chmod +x fix-ingress.sh
./fix-ingress.sh

脚本会自动完成三件事：

检查当前controller镜像版本
将镜像替换为安全版本（示例中的 v1.10.1 仅供参考，实际请根据官方公告填写绿标版本）
监控滚动更新完成

注意：版本号一定要根据官方最新的安全建议填写，不要直接用示例中的 v1.10.1，因为漏洞披露时间不同，建议访问 ingress-nginx release 页面确认最新安全版本。

三、常见报错与避坑

坑1：脚本卡在滚动更新阶段
检查Pod状态 kubectl get pods -n ingress-nginx，如果新Pod起不来（CrashLoopBackOff），很可能是因为镜像拉取失败或配置不兼容。先回滚备份：kubectl apply -f ingress-nginx-backup.yaml，然后手动排查镜像地址是否写对。

坑2：升级后旧版配置遗留下来
有些漏洞和配置参数有关（比如 enable-ssl-passthrough），光升级镜像是不够的。建议在脚本中额外添加 ConfigMap 配置更新，或者手动修改 ConfigMap：

kubectl edit configmap ingress-nginx-controller -n ingress-nginx

按官方建议添加或修改关键参数值。

坑3：多集群环境
如果集群有多个 Ingress Controller（比如同时使用不同命名空间），脚本只处理指定的 namespace。你可以修改脚本开头的 NAMESPACE 和 DEPLOYMENT_NAME 变量来适配。

四、如何验证漏洞确实被修复了？

跑完脚本后，至少做三项检查：

检查Pod镜像版本

   kubectl get pods -n ingress-nginx -o jsonpath='{.items[*].spec.containers[0].image}' | tr ' ' '\n'

确认所有Pod的镜像版本都变成了你升级的目标版本。

检查日志

   kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=50

没有 error 或 panic 级别日志即为正常。

验证业务访问

如果集群内还有测试域名，直接访问看 502/403 是否消失。
最好用工具扫描一下曾经利用漏洞的请求，确认已无法生效（比如尝试发送特殊Header，应该被正常拦截）。

五、高频问题解答

Q：脚本改了镜像版本，配置需要手动调整吗？
A：多数情况下只需升级镜像即可堵住漏洞，但少数漏洞（如CVE-2023-5044）还涉及use-forwarded-headers参数。建议查看对应CVE的官方修复说明，必要的话在脚本后追加ConfigMap修改。

Q：能不能把脚本集成到CI/CD里？
A：完全可以。把脚本放到流水线任务中，作为安全更新阶段即可。注意提前加入版本校验逻辑，只在受影响版本范围内执行升级。

Q：升级会影响现有流量吗？
A：采用滚动更新策略，理论上不会中断，但建议在低谷期执行，并提前配置好Pod反亲和与副本数>=2。

如果你处理的是特定CVE，或者集群遇到滚动更新失败，建议先按本文步骤完整执行，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。

住宅机器降噪散热改造24小时稳定挂机运行方案

多线路冗余AI中转网关防止接口掉线断连故障