Hello Kubernetes Community,
A security issue was discovered in kube-apiserver that allows an aggregated API server to redirect client traffic to any URL. This could lead to the client performing unexpected actions as well as forwarding the client's API server credentials to third parties.
This issue has been rated medium (https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:L/A:L) (5.1), and assigned CVE-2022-3172
All Kubernetes clusters with the following versions that are running aggregated API servers are impacted. To identify if you have aggregated API servers configured, run the following command:
Aside from upgrading, no direct mitigation is available.
Aggregated API servers are a trusted part of the Kubernetes control plane, and configuring them is a privileged administrative operation. Ensure that only trusted cluster administrators are allowed to create or modify APIService
configuration, and follow security best practices with any aggregated API servers that may be in use.
Fix impact: The fix blocks all 3XX responses from aggregated API servers by default. This may disrupt an aggregated API server that relies on redirects as part of its normal function. If all current and future aggregated API servers are considered trustworthy and redirect functionality is required, set the --aggregator-reject-forwarding-redirect
Kubernetes API server flag to false
to restore the previous behavior.
To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade
Kubernetes audit log events indicate the HTTP status code sent to the client via the responseStatus.code
field. This can be used to detect if an aggregated API server is redirecting clients.
If you find evidence that this vulnerability has been exploited, please contact secu...@kubernetes.io
See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/112513
This vulnerability was reported by Nicolas Joly & Weinong Wang @weinong from Microsoft.
The issue was fixed and coordinated by Di Jin @jindijamie @enj @liggitt @lavalamp @deads2k and @puerco.
Thank You,
Mo Khan on behalf of the Kubernetes Security Response Committee