Kubernetes, a tool that powers much modern native cloud infrastructure, just got its first big security bug – and it’s a mammoth one. The flaw could give an attacker unfettered access to the software applications that rely on the tool to operate.
Kubernetes is a software tool that manages large numbers of containers. These are similar to the virtual machines that run multiple operating systems on the same physical computer, but they have a key difference. Instead of housing a complete operating system, containers house only what’s needed for a particular application to run (such as software dependencies, system libraries etc), while sharing a host operating system with other containers.
Containers are small, nimble operating environments that are designed to run the same way across multiple computing environments, removing “but it worked when we tested it!” issues. Companies can run tens or even hundreds of thousands of containers, and that can make deploying, updating and managing them all a serious challenge. That’s where Kubernetes comes in. It manages containers in groups called pods.
The program, which originally started as an open-source project from Google and is now managed by the Linux Foundation’s Cloud Native Computing Foundation (CNCF), sprang its first serious leak with the flaw, which gives an attacker deep access to a Kubernetes installation. It enables a specially crafted request to connect with Kubernetes servers and make their own requests.
The Kubernetes team announced the flaw as CVE-2018-1002105. The vulnerability lies with the Kubernetes API server – which is a software tool that enables Kubernetes users to send instructions to Kubernetes pods over an HTTP API (Application Programming Interface) – and the way that API server communicates with a Kubernetes pod.
The API server authorises user requests via certificate-based authentication. But if the user sends a malformed request designed to return an error, the server leaves the line of communication open with the pod and simply lets subsequent requests through without checking to see if the user is authorized. This effectively escalates the user’s privileges.
This issue enables a regular user to acquire exec (very high privileged) access to any container on the node, including those that have read/write access to the host filesystem. They get access to all running workloads, including all the data flowing between them.
Attackers could use this flaw to steal data, bring applications grinding to a halt, or run their own malicious commands.
There are two variants on the exploit, one that uses Kubernetes’ aggregated API servers, and which is accessible by all users. The other uses a call to an API known as an exec/attach/portforward, which is typically only available to users with admin/edit roles.
Red Hat provided more detail about how the flaw affects version 3.0 of OpenShift, its own container platform that uses Kubernetes as a core component.
Kubernetes has already patched the flaw, and users of systems that support automated patches should already be protected. Those that aren’t need to get their Kubernetes installations patched pronto.
9 comments on “Kubernetes cloud computing bug could rain data for attackers”
Cloud computing and storage has always been insecure and this proves it. I will NEVER use the cloaud for anything. If a software application requires its use then I will not use that software, simple.
For the most part I would have said that cloud computing, when used correctly, is actually safer. For the most part our organisation has made the move across to MS Azure and I cannot praise Microsoft enough for how they have helped secure our environment. Yes there are risks, but they notify us as soon as somethings identified and within half an hour the issues are generally resolved.
I think you just posted a response to a service hosted in a cloud.
What about all those services, from insurance firms through to telephone companies, that store your data in the cloud without you even being aware?
Do people run Kubernetes exposed to the public internet? Personally, I try to limit all command and control to be only available behind a firewall or VPN.
They can be. In one case Tesla’s Kubernetes instances were hacked because developers had left them configured without an administrative password. The attackers installed coin mining programs on Tesla’s cloud.
Shodan turns up about 21,000 results for Kubernetes.
At least in these virtual empires when a piece of the foundation is broke you can fix it before the building falls, that is if you catch and patch it before the rats eat all your grain.
The least you could do is make it simpler to unsubscribe. I clicked on your website once and now can’t get rid of you. Security breach? Too bad that’s what it takes for you to listen. Take me off your list