 |
| kubernetes api server |
Kubernetes has become by far the most popular cloud container orchestration system. It's only a matter of time before his first major safety hole is discovered. And the bug, CVE-2018-1002105, also called Kubernetes privilege escalation, is a doozy. This is a critical security hole in CVSS 9.8.
With a specially crafted network request, any user can establish a connection to a Kubernetes API server (application programming interface) to a primary server. Once established, an attacker can send arbitrary requests via the network connection directly to this server. Adding insult to injury, these requests are authenticated with Transport Layer Security (TLS) credentials from the Kubernetes API server.
Also: How to quickly install Kubernetes on Ubuntu TechRepublic
Can you tell the root? I knew you could.
Even worse: "In default configurations, all users (authenticated and unauthenticated) are allowed to make discovery API calls that allow this escalation." So, yes, anyone who is aware of this hole can take control of your Kubernetes cluster.
Oh, and for the final shock: "There is no easy way to detect if this vulnerability has been used because unauthorized requests are made through an established connection, they are not included in audit logs. Kubernetes API Server Requests appear in globalized or aggregated API server logs, but can not be distinguished from properly authorized and mandated requests through the Kubernetes API server. "
In other words, Red Hat stated, "The privilege escalation vulnerability allows any user to have full administrator privileges on any compute node running in a Kubernetes container, which is a big problem. This actor can not only steal sensitive data or inject malicious code, but they can also reduce applications and production services inside a company's firewall. "
Fortunately, there is a solution, but some of you will not like it. You must upgrade Kubernetes. Now. Specifically, there is a corrected version of Kubernetes v1.10.11, v1.11.5, v1.12.3, and v1.1.0.0-rc.1.
If you are still using Kubernetes v1.0.x-1.9.x, stop. Updated to a corrected version. If for some reason you can not get up, there are remedies, but they are almost worse than the disease. You must suspend the use of the aggregated API servers and remove transfer permissions from the pod / attach / port executive of users who should not have full access to the cubelet API. Jordan Liggitt, Google's software engineer who corrected the bug, said the mitigation measures may be disruptive. You think?
The only solution is to upgrade Kubernetes.
Also: Kubernetes: The guide of the smart TechRepublic
Any program, including Kubernetes, is vulnerable. Kubernetes distributors already publish patches.
Red Hat reports that all of its "Kubernetes-based services and products, including the Red Hat OpenShift container platform, Red Hat OpenShift Online, and Red Hat OpenShift Dedicated - are affected." Red Hat has started providing patches and service updates to affected users.
To everyone's knowledge, no one has yet taken advantage of the security hole to attack anyone. Darren Shepard, chief architect and co-founder of Rancher Labs, discovered the bug and reported it using Kubernetes' vulnerability reporting process.
But - and this is a big one - abusing vulnerability would leave no obvious trace in the newspapers. And now that the privilege escalation flaw in Kubernetes is canceled, there's only a matter of time left before it gets abused.
So, once again and with emotion, upgrade your Kubernetes systems before your business finds itself in a troubled world.
0 Comments