You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A security issue was discovered in Kubernetes where users may have access to secure endpoints in the control plane network. Kubernetes clusters are only affected if an untrusted user can modify Node objects and send proxy requests to them.
Kubernetes supports node proxying, which allows clients of kube-apiserver to access endpoints of a Kubelet to establish connections to Pods, retrieve container logs, and more. While Kubernetes already validates the proxying address for Nodes, a bug in kube-apiserver made it possible to bypass this validation. Bypassing this validation could allow authenticated requests destined for Nodes to to the API server's private network.
These releases will be published over the course of today, November 10th.
Fix impact: In some cases, the fix can break clients that depend on the nodes/proxy subresource, specifically if a kubelet advertises a localhost or link-local address to the Kubernetes control plane.
How can we reproduce it (as minimally and precisely as possible)?
Hi @pacoxu,
Thanks for opening an issue!
We will look into it as soon as possible.
Details
Instructions for interacting with me using comments are available here.
If you have questions or suggestions related to my behavior, please file an issue against the [gh-ci-bot](https://github.com/wzshiming/gh-ci-bot) repository.
What happened?
kubernetes/kubernetes#113757
What did you expect to happen?
A security issue was discovered in Kubernetes where users may have access to secure endpoints in the control plane network. Kubernetes clusters are only affected if an untrusted user can modify Node objects and send proxy requests to them.
Kubernetes supports node proxying, which allows clients of kube-apiserver to access endpoints of a Kubelet to establish connections to Pods, retrieve container logs, and more. While Kubernetes already validates the proxying address for Nodes, a bug in kube-apiserver made it possible to bypass this validation. Bypassing this validation could allow authenticated requests destined for Nodes to to the API server's private network.
This issue has been rated Medium (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H), and assigned CVE-2022-3294
These releases will be published over the course of today, November 10th.
Fix impact: In some cases, the fix can break clients that depend on the nodes/proxy subresource, specifically if a kubelet advertises a localhost or link-local address to the Kubernetes control plane.
How can we reproduce it (as minimally and precisely as possible)?
Fixed Versions
• Kubernetes kube-apiserver v1.25.4
• Kubernetes kube-apiserver v1.24.8
• Kubernetes kube-apiserver v1.23.14
• Kubernetes kube-apiserver v1.22.16
Anything else we need to know?
No response
The text was updated successfully, but these errors were encountered: