​Kubernetes' first major security hole discovered

There's now an invisible way to hack into the popular cloud container orchestration system Kubernetes.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

Kubernetes has become the most popular cloud container orchestration system by far, so it was only a matter of time until its first major security hole was discovered. And the bug, CVE-2018-1002105, aka the Kubernetes privilege escalation flaw, is a doozy. It's a CVSS 9.8 critical security hole.

With a specially crafted network request, any user can establish a connection through the Kubernetes application programming interface (API) server to a backend server. Once established, an attacker can send arbitrary requests over the network connection directly to that backend. Adding insult to injury, these requests are authenticated with the Kubernetes API server's Transport Layer Security (TLS) credentials.

Also: How to quickly install Kubernetes on Ubuntu TechRepublic

Can you say root? I knew you could.

Worse still, "In default configurations, all users (authenticated and unauthenticated) are allowed to perform discovery API calls that allow this escalation." So, yes, anyone who knows about this hole can take command of your Kubernetes cluster.

Oh, and for the final jolt of pain: "There is no simple way to detect whether this vulnerability has been used. Because the unauthorized requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or server log. The requests do appear in the kubelet or aggregated API server logs, but are indistinguishable from correctly authorized and proxied requests via the Kubernetes API server."

In other words, Red Hat said, "The privilege escalation flaw makes it possible for any user to gain full administrator privileges on any compute node being run in a Kubernetes pod. This is a big deal. Not only can this actor steal sensitive data or inject malicious code, but they can also bring down production applications and services from within an organization's firewall."

Fortunately, there is a fix, but some of you aren't going to like it. You must upgrade Kubernetes. Now. Specifically, there are patched version of Kubernetes v1.10.11, v1.11.5, v1.12.3, and v1.13.0-rc.1.

If you're still using Kubernetes v1.0.x-1.9.x, stop. Update to a patched version. If for some reason you can't move up, there are cures, but they're almost worse than the disease. You must suspend use of aggregated API servers and remove pod exec/attach/portforward permissions from users that should not have full access to the kubelet API. Jordan Liggitt, the Google software engineer who fixed the bug, said these mitigations are likely to be disruptive. You think?

The only real fix is to upgrade Kubernetes.

Also: Kubernetes: The smart person's guide TechRepublic

Any program, which includes Kubernetes, is vulnerable. Kubernetes distributors are already releasing fixes.

Red Hat reports all its "Kubernetes-based services and products -- including Red Hat OpenShift Container Platform, Red Hat OpenShift Online, and Red Hat OpenShift Dedicated -- are affected." Red Hat has begun delivering patches and service updates to affected users.

As far as anyone knows, no one has used the security hole to attack anyone yet. Darren Shepard, chief architect and co-founder at Rancher Labs, discovered the bug and reported it using the Kubernetes vulnerability reporting process.

But -- and it's a big but -- abusing the vulnerability would have left no obvious traces in the logs. And, now that news of the Kubernetes privilege escalation flaw is out, it's only a matter of time until it's abused.

So, once more and with feeling, upgrade your Kubernetes systems now before your company ends up in a world of trouble.

Cloud services: 24 lesser-known web services your business needs to try

Related stories:

Editorial standards