|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: "ingress-nginx CVE-2025-1974 须知" |
| 4 | +date: 2025-03-24T12:00:00-08:00 |
| 5 | +slug: ingress-nginx-CVE-2025-1974 |
| 6 | +author: > |
| 7 | + Tabitha Sable (Kubernetes 安全响应委员会) |
| 8 | +translator: > |
| 9 | + [Michael Yao](https://github.com/windsonsea) (DaoCloud) |
| 10 | +--- |
| 11 | +<!-- |
| 12 | +layout: blog |
| 13 | +title: "Ingress-nginx CVE-2025-1974: What You Need to Know" |
| 14 | +date: 2025-03-24T12:00:00-08:00 |
| 15 | +slug: ingress-nginx-CVE-2025-1974 |
| 16 | +author: > |
| 17 | + Tabitha Sable (Kubernetes Security Response Committee) |
| 18 | +--> |
| 19 | + |
| 20 | +<!-- |
| 21 | +Today, the ingress-nginx maintainers have [released patches for a batch of critical vulnerabilities](https://github.com/kubernetes/ingress-nginx/releases) that could make it easy for attackers to take over your Kubernetes cluster. If you are among the over 40% of Kubernetes administrators using [ingress-nginx](https://github.com/kubernetes/ingress-nginx/), you should take action immediately to protect your users and data. |
| 22 | +--> |
| 23 | +今天，ingress-nginx 项目的维护者们[发布了一批关键漏洞的修复补丁](https://github.com/kubernetes/ingress-nginx/releases)， |
| 24 | +这些漏洞可能让攻击者轻易接管你的 Kubernetes 集群。目前有 40% 以上的 Kubernetes 管理员正在使用 |
| 25 | +[ingress-nginx](https://github.com/kubernetes/ingress-nginx/)， |
| 26 | +如果你是其中之一，请立即采取行动，保护你的用户和数据。 |
| 27 | + |
| 28 | +<!-- |
| 29 | +## Background |
| 30 | +
|
| 31 | +[Ingress](/docs/concepts/services-networking/ingress/) is the traditional Kubernetes feature for exposing your workload Pods to the world so that they can be useful. In an implementation-agnostic way, Kubernetes users can define how their applications should be made available on the network. Then, an [ingress controller](/docs/concepts/services-networking/ingress-controllers/) uses that definition to set up local or cloud resources as required for the user’s particular situation and needs. |
| 32 | +--> |
| 33 | +## 背景 {#background} |
| 34 | + |
| 35 | +[Ingress](/zh-cn/docs/concepts/services-networking/ingress/) |
| 36 | +是 Kubernetes 提供的一种传统特性，可以将你的工作负载 Pod 暴露给外部世界，方便外部用户使用。 |
| 37 | +Kubernetes 用户可以用与实现无关的方式来定义应用如何在网络上可用。 |
| 38 | +[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/)会根据定义， |
| 39 | +配置所需的本地资源或云端资源，以满足用户的特定场景和需求。 |
| 40 | + |
| 41 | +<!-- |
| 42 | +Many different ingress controllers are available, to suit users of different cloud providers or brands of load balancers. Ingress-nginx is a software-only ingress controller provided by the Kubernetes project. Because of its versatility and ease of use, ingress-nginx is quite popular: it is deployed in over 40% of Kubernetes clusters\! |
| 43 | +
|
| 44 | +Ingress-nginx translates the requirements from Ingress objects into configuration for nginx, a powerful open source webserver daemon. Then, nginx uses that configuration to accept and route requests to the various applications running within a Kubernetes cluster. Proper handling of these nginx configuration parameters is crucial, because ingress-nginx needs to allow users significant flexibility while preventing them from accidentally or intentionally tricking nginx into doing things it shouldn’t. |
| 45 | +--> |
| 46 | +为了满足不同云厂商用户或负载均衡器产品的需求，目前有许多不同类型的 Ingress 控制器。 |
| 47 | +ingress-nginx 是 Kubernetes 项目提供的纯软件的 Ingress 控制器。 |
| 48 | +ingress-nginx 由于灵活易用，非常受用户欢迎。它已经被部署在超过 40% 的 Kubernetes 集群中！ |
| 49 | + |
| 50 | +ingress-nginx 会将 Ingress 对象中的要求转换为 Nginx（一个强大的开源 Web 服务器守护进程）的配置。 |
| 51 | +Nginx 使用这些配置接受请求并将其路由到 Kubernetes 集群中运行的不同应用。 |
| 52 | +正确处理这些 Nginx 配置参数至关重要，因为 ingress-nginx 既要给予用户足够的灵活性， |
| 53 | +又要防止用户无意或有意诱使 Nginx 执行其不应执行的操作。 |
| 54 | + |
| 55 | +<!-- |
| 56 | +## Vulnerabilities Patched Today |
| 57 | +
|
| 58 | +Four of today’s ingress-nginx vulnerabilities are improvements to how ingress-nginx handles particular bits of nginx config. Without these fixes, a specially-crafted Ingress object can cause nginx to misbehave in various ways, including revealing the values of [Secrets](/docs/concepts/configuration/secret/) that are accessible to ingress-nginx. By default, ingress-nginx has access to all Secrets cluster-wide, so this can often lead to complete cluster takeover by any user or entity that has permission to create an Ingress. |
| 59 | +--> |
| 60 | +## 今日修复的漏洞 {#vulnerabilities-patched-today} |
| 61 | + |
| 62 | +今天修复的四个 ingress-nginx 漏洞都是对 ingress-nginx 如何处理特定 Nginx 配置细节的改进。 |
| 63 | +如果不打这些修复补丁，一个精心构造的 Ingress 资源对象就可以让 Nginx 出现异常行为， |
| 64 | +包括泄露 ingress-nginx 可访问的 [Secret](/zh-cn/docs/concepts/configuration/secret/) |
| 65 | +的值。默认情况下，ingress-nginx 可以访问集群范围内的所有 Secret，因此这往往会导致任一有权限创建 |
| 66 | +Ingress 的用户或实体接管整个集群。 |
| 67 | + |
| 68 | +<!-- |
| 69 | +The most serious of today’s vulnerabilities, [CVE-2025-1974](https://github.com/kubernetes/kubernetes/issues/131009), rated [9.8 CVSS](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), allows anything on the Pod network to exploit configuration injection vulnerabilities via the Validating Admission Controller feature of ingress-nginx. This makes such vulnerabilities far more dangerous: ordinarily one would need to be able to create an Ingress object in the cluster, which is a fairly privileged action. When combined with today’s other vulnerabilities, **CVE-2025-1974 means that anything on the Pod network has a good chance of taking over your Kubernetes cluster, with no credentials or administrative access required**. In many common scenarios, the Pod network is accessible to all workloads in your cloud VPC, or even anyone connected to your corporate network\! This is a very serious situation. |
| 70 | +--> |
| 71 | +本次最严重的漏洞是 [CVE-2025-1974](https://github.com/kubernetes/kubernetes/issues/131009)， |
| 72 | +CVSS 评分高达 [9.8](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)， |
| 73 | +它允许 Pod 网络中的任意实体通过 ingress-nginx 的验证性准入控制器特性滥用配置注入漏洞。 |
| 74 | +这种机制使得这些漏洞会产生更危险的情形：攻击者通常需要能够在集群中创建 Ingress 对象（这是一种较高权限的操作）。 |
| 75 | +当结合使用今天修复的其他漏洞（比如 CVE-2025-1974）， |
| 76 | +**就意味着 Pod 网络中的任何实体都有极大可能接管你的 Kubernetes 集群，而不需要任何凭证或管理权限**。 |
| 77 | +在许多常见场景下，Pod 网络可以访问云端 VPC 中的所有工作负载，甚至能访问连接到你公司内网的任何人的机器！ |
| 78 | +这是一个非常严重的安全风险。 |
| 79 | + |
| 80 | +<!-- |
| 81 | +Today, we have [released ingress-nginx v1.12.1 and v1.11.5](https://github.com/kubernetes/ingress-nginx/releases), which have fixes for all five of these vulnerabilities. |
| 82 | +
|
| 83 | +## Your next steps |
| 84 | +
|
| 85 | +First, determine if your clusters are using ingress-nginx. In most cases, you can check this by running `kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx` with cluster administrator permissions. |
| 86 | +--> |
| 87 | +我们今天已经[发布了 ingress-nginx v1.12.1 和 v1.11.5](https://github.com/kubernetes/ingress-nginx/releases)， |
| 88 | +这两个版本修复了所有这 5 个漏洞。 |
| 89 | + |
| 90 | +## 你需要做什么 {#your-next-steps} |
| 91 | + |
| 92 | +首先，确定你的集群是否在使用 ingress-nginx。大多数情况下，你可以使用集群管理员权限运行以下命令进行检查： |
| 93 | + |
| 94 | +```shell |
| 95 | +kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx |
| 96 | +``` |
| 97 | + |
| 98 | +<!-- |
| 99 | +**If you are using ingress-nginx, make a plan to remediate these vulnerabilities immediately.** |
| 100 | +
|
| 101 | +**The best and easiest remedy is to [upgrade to the new patch release of ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/).** All five of today’s vulnerabilities are fixed by installing today’s patches. |
| 102 | +
|
| 103 | +If you can’t upgrade right away, you can significantly reduce your risk by turning off the Validating Admission Controller feature of ingress-nginx. |
| 104 | +--> |
| 105 | +**如果你在使用 ingress-nginx，请立即针对这些漏洞制定补救计划。** |
| 106 | + |
| 107 | +**最简单且推荐的补救方案是[立即升级到最新补丁版本](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)。** |
| 108 | +安装今天的补丁，就能修复所有这 5 个漏洞。 |
| 109 | + |
| 110 | +如果你暂时无法升级，可以通过关闭 ingress-nginx 的验证性准入控制器特性来显著降低风险。 |
| 111 | + |
| 112 | +<!-- |
| 113 | +* If you have installed ingress-nginx using Helm |
| 114 | + * Reinstall, setting the Helm value `controller.admissionWebhooks.enabled=false` |
| 115 | +* If you have installed ingress-nginx manually |
| 116 | + * delete the ValidatingWebhookconfiguration called `ingress-nginx-admission` |
| 117 | + * edit the `ingress-nginx-controller` Deployment or Daemonset, removing `--validating-webhook` from the controller container’s argument list |
| 118 | +--> |
| 119 | +* 如果你使用 Helm 安装了 ingress-nginx |
| 120 | + * 重新安装，设置 Helm 参数 `controller.admissionWebhooks.enabled=false` |
| 121 | +* 如果你是手动安装的 |
| 122 | + * 删除名为 `ingress-nginx-admission` 的 ValidatingWebhookConfiguration |
| 123 | + * 编辑 `ingress-nginx-controller` Deployment 或 DaemonSet，从控制器容器的参数列表中移除 `--validating-webhook` |
| 124 | + |
| 125 | +<!-- |
| 126 | +If you turn off the Validating Admission Controller feature as a mitigation for CVE-2025-1974, remember to turn it back on after you upgrade. This feature provides important quality of life improvements for your users, warning them about incorrect Ingress configurations before they can take effect. |
| 127 | +--> |
| 128 | +如果你为了缓解 CVE-2025-1974 造成的风险而关闭了验证性准入控制器特性， |
| 129 | +请在升级完成后记得重新开启此特性。这个特性可以为你的用户提供重要的生命期帮助， |
| 130 | +可以在错误的 Ingress 配置在生效之前及时提醒用户。 |
| 131 | + |
| 132 | +<!-- |
| 133 | +## Conclusion, thanks, and further reading |
| 134 | +
|
| 135 | +The ingress-nginx vulnerabilities announced today, including CVE-2025-1974, present a serious risk to many Kubernetes users and their data. If you use ingress-nginx, you should take action immediately to keep yourself safe. |
| 136 | +
|
| 137 | +Thanks go out to Nir Ohfeld, Sagi Tzadik, Ronen Shustin, and Hillai Ben-Sasson from Wiz for responsibly disclosing these vulnerabilities, and for working with the Kubernetes SRC members and ingress-nginx maintainers (Marco Ebert and James Strong) to ensure we fixed them effectively. |
| 138 | +--> |
| 139 | +## 总结、致谢与更多参考 {#conclusion-thanks-and-further-reading} |
| 140 | + |
| 141 | +今天公布的包括 CVE-2025-1974 在内的 ingress-nginx 漏洞对许多 Kubernetes 用户及其数据构成了严重风险。 |
| 142 | +如果你正在使用 ingress-nginx，请立即采取行动确保自身安全。 |
| 143 | + |
| 144 | +我们要感谢来自 Wiz 的 Nir Ohfeld、Sagi Tzadik、Ronen Shustin 和 Hillai Ben-Sasson， |
| 145 | +他们负责任地披露了这些漏洞，并与 Kubernetes 安全响应委员会成员以及 ingress-nginx |
| 146 | +维护者（Marco Ebert 和 James Strong）协同合作，确保这些漏洞被有效修复。 |
| 147 | + |
| 148 | +<!-- |
| 149 | +For further information about the maintenance and future of ingress-nginx, please see this [GitHub issue](https://github.com/kubernetes/ingress-nginx/issues/13002) and/or attend [James and Marco’s KubeCon/CloudNativeCon EU 2025 presentation](https://kccnceu2025.sched.com/event/1tcyc/). |
| 150 | +
|
| 151 | +For further information about the specific vulnerabilities discussed in this article, please see the appropriate GitHub issue: [CVE-2025-24513](https://github.com/kubernetes/kubernetes/issues/131005), [CVE-2025-24514](https://github.com/kubernetes/kubernetes/issues/131006), [CVE-2025-1097](https://github.com/kubernetes/kubernetes/issues/131007), [CVE-2025-1098](https://github.com/kubernetes/kubernetes/issues/131008), or [CVE-2025-1974](https://github.com/kubernetes/kubernetes/issues/131009) |
| 152 | +--> |
| 153 | +有关 ingress-nginx 的维护和未来的更多信息， |
| 154 | +请参阅[这个 GitHub Issue](https://github.com/kubernetes/ingress-nginx/issues/13002)， |
| 155 | +或参与 [James 和 Marco 在 KubeCon/CloudNativeCon EU 2025 的演讲](https://kccnceu2025.sched.com/event/1tcyc/)。 |
| 156 | + |
| 157 | +关于本文中提到的具体漏洞的信息，请参阅以下 GitHub Issue： |
| 158 | + |
| 159 | +- [CVE-2025-24513](https://github.com/kubernetes/kubernetes/issues/131005) |
| 160 | +- [CVE-2025-24514](https://github.com/kubernetes/kubernetes/issues/131006) |
| 161 | +- [CVE-2025-1097](https://github.com/kubernetes/kubernetes/issues/131007) |
| 162 | +- [CVE-2025-1098](https://github.com/kubernetes/kubernetes/issues/131008) |
| 163 | +- [CVE-2025-1974](https://github.com/kubernetes/kubernetes/issues/131009) |
0 commit comments