Kubernetes API Server Vulnerability
A Kubernetes vulnerability (CVE-2019-11247) has been identified where the API server mistakenly allows access to a cluster-scoped custom resource, if the request is made as if the resource were namespaced. Authorisations for the resource accessed in this manner are enforced using roles and role bindings within the namespace. This means that a user with access only to a resource in one namespace could create, view update or delete the cluster-scoped resource (according to their namespace role privileges).
This vulnerability has been given an initial severity of Medium with a score of 5.0. Details of how this score was calculated can be seen here: https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
- Kubernetes API server
- Affected versions
- Kubernetes v1.7-1.12.x
- Kubernetes v1.13.0-1.13.8 (resolved in v1.13.9)
- Kubernetes v1.14.0-1.14.4 (resolved in v1.14.5)
- Kubernetes v1.15.0-1.15.1 (resolved in v1.15.2)
All clusters that have rolebindings to roles and clusterroles that include authorisation rules for cluster-scoped custom resources.
A user with access to custom resources in a single namespace can access custom resources with cluster scope.
In order to detect whether this vulnerability has been exploited, logging of API server requests must be enabled. A search of the logs for you namespaced access of a cluster-scoped resource could indicate that the vulnerability was used to improperly access the resource.
The vulnerability has been fixed in the following versions of Kubernetes:
Users should update to one of the above listed versions.
To mitigate against the vulnerability in an unpatched version, remove authorisation rules that grant access to cluster-scoped resources within namespaces. For example, RBAC roles and clusterroles intended to be referenced by rolebindings should not grant access to resources:[*], apiGroups:[*], or grant access to cluster-scoped custom resources.
Patched builds of the 1.13.8, 1.14.4, and 1.15.1 kube-apiserver snap were published by Canonical on July 29 2019. Users of those snap versions, including users of Charmed Kubernetes, are already patched.
2019 Aug 5 at 16:00 UTC: the issue is made public