A very serious security flaw (CVE-2018-1002105) has just been found and patched for Kubernetes. It affects versions prior to v1.10.11, v1.11.5, and v1.12.3. The newly released v1.13 is not affected. Update your Kubernetes clusters immediately, and then come back to read about it here!
Security impact
The security flaw allows any authenticated Kubernetes user to get administrative access to the cluster (using standard security settings). Because of that, and how reliably the flaw can be exploited, it has been awarded a CVSS3 score of 9.8 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). That makes it one of the most serious bugs that Kubernetes has had, and its impact is huge. If you are running a cluster older than v1.10.11, v1.11.5, or v1.12.3, you must upgrade as soon as possible.
Some deployments are not affected. For instance if you use the admin account for everything (don’t!). Or if you just have a development installations of minikube. Because you are running as admin anyway, privilege escalation is rather inconsequential. But for enterprise users who rely on RBAC to enforce security policies, the impact is tremendous. Hence the CVSS3 score of 9.8.
Malicious activity does not show up in the Kubernetes API server’s audit log. This means that administrators cannot reliably determine if their systems have been abused or not. The activity shows up in kubelet logs, but is indistinguishable from normal activity.
All secrets must be assumed to have been compromised.
How do I know if I am affected?
You can see which version of Kubernetes your nodes are running by running: kubectl get nodes. Your output tells you which version of Kubernetes is on each node.
Because malicious activity enabled by the bug will not show up in the API server’s audit logs (and you cannot reliably find it in the logs of kubelet), you should upgrade immediately and assume that any secret data has been compromised.
CVE-2018-1002105 explained
The bug is in the Kubernetes API server. Any authenticated user can make API requests to the API server. Its job is to determine if those requests should be allowed or not, and if so, it tells other components to carry out the needed work. This is where the security flaw comes in.
Users who are allowed to establish backend connections through the API server can trick the API server. The default security settings let all users do this, as this allows them to do service discovery. By forming a special API request, the API server can be fooled to connect essentially as “itself” to the backend components. Thus, the request is carried out using the highest level of permissions and not in the context of the original user. And worse: the request does not show up in the Kubernetes API server’s audit log.
Users can also use the API server to connect to a running Pod. This allows e.g. the exec, attach, and portforward API calls. The security flaw and those API calls can be combined. If so, a user can run any API request against the kubelet API of the node where a targeted Pod is running. This includes listing all Pods on the node and running arbitrary commands inside these Pods. And getting the output.
Mitigation
How to upgrade Kubernetes depends on how you have installed it. Refer to your Kubernetes distribution or installation tool for instructions. Ensure that you run backups of your masters before you act. We will release a blog post soon about how this is done and update this one with the link.
Because there is no way of telling whether this security flaw has been actively used or not, you must assume that your sensitive data has been compromised. Rotate passwords and other secrets.
