Hello Kubernetes Community,
A security issue was discovered in Kubernetes where users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group without authorization.
This issue has been rated Medium (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), and assigned CVE-2022-3162
Am I vulnerable?
Clusters are impacted by this vulnerability if all of the following are true:
-
There are 2+ CustomResourceDefinitions sharing the same API group
-
Users have cluster-wide list or watch authorization on one of those custom resources.
-
The same users are not authorized to read another custom resource in the same API group.
Affected Versions- Kubernetes kube-apiserver <= v1.25.3
-
Kubernetes kube-apiserver <= v1.24.7
-
Kubernetes kube-apiserver <= v1.23.13
-
Kubernetes kube-apiserver <= v1.22.15
How do I mitigate this vulnerability?
Upgrading the kube-apiserver to a fixed version mitigates this vulnerability.
Prior to upgrading, this vulnerability can be mitigated by avoiding granting cluster-wide list and watch permissions.
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
These releases will be published over the course of today, November 10th.
Detection
Requests containing .. in the request path are a likely indicator of exploitation. Request paths may be captured in API audit logs, or in kube-apiserver HTTP logs.
If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io
Additional Details
See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/113756
Acknowledgements
This vulnerability was reported by Richard Turnbull of NCC Group as part of the Kubernetes Audit.
Thank You,
Tim Allclair on behalf of the Kubernetes Security Response Committee