Kubernetes became by far the most popular cloud container system. So actually it was only a matter of time until his first major security flaw was discovered.
And so it was, because recently The first major security flaw in Kubernetes was released under CVE-2018-1002105, also known as the privilege escalation failure.
This major flaw in Kubernetes is a problem as it is a critical CVSS 9.8 security hole. In the event of the first major Kubernetes security flaw.
Details of the error
With a specially designed request network, any user can establish a connection through from the application programming interface server (API) Kubernetes to a backend server.
Once established, an attacker can send arbitrary requests over the network connection directly to that backend in which at all times the objective is that server.
These requests are authenticated with the TLS credentials (Transport Layer Security) from the Kubernetes API server.
Worse still, in the default configuration, all users (authenticated or not) can run API discovery calls that allow for this privilege escalation by the attacker.
So then, anyone who knows that hole can take the opportunity to take command of their Kubernetes cluster.
At the moment there is no easy way to detect if this vulnerability was used previously.
As unauthorized requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or the server log.
Requests appear in the kubelet logs or aggregate API server, but they are distinguished from properly authorized and proxy requests through the Kubernetes API server.
Abuse this new vulnerability in Kubernetes it wouldn't leave obvious traces in the logs, so now that the Kubernetes bug is exposed, it's only a matter of time until it's used.
In other words, Red Hat said:
The privilege escalation flaw allows any unauthorized user to gain full administrator privileges on any compute node running in a Kubernetes pod.
This is not just a theft or an opening to inject malicious code, it can also reduce application and production services within an organization's firewall.
Any program, including Kubernetes, is vulnerable. Kubernetes distributors are already releasing fixes.
Red Hat reports that all of its Kubernetes-based products and services including Red Hat OpenShift Container Platform, Red Hat OpenShift Online, and Red Hat OpenShift Dedicated are affected.
Red Hat began providing patches and service updates to affected users.
As far as is known, no one used the security breach to attack yet. Darren Shepard, chief architect and co-founder of Rancher laboratory, discovered the bug and reported it using the Kubernetes vulnerability reporting process.
How to correct this fault?
Fortunately, a fix for this bug has already been released.. In which only they are asked to perform a Kubernetes update so they can choose some of the Kubernetes patched versions v1.10.11, v1.11.5, v1.12.3, and v1.13.0-RC.1.
So if you are still using any of the Kubernetes v1.0.x-1.9.x versions, it is recommended that you upgrade to a fixed version.
If for some reason they can't update Kubernetes and they want to stop this failure, it is necessary that they carry out the following process.
You should stop using the server aggregates API or remove pod exec / attach / portforward permissions for users who should not have full access to the kubelet API.
Jordan Liggitt, the Google software engineer who fixed the bug, said those measures will likely be detrimental.
So the only real solution against this security flaw is to perform the corresponding Kubernetes update.