An ever-increasing number of companies are using Kubernetes to manage and scale applications and services. Originally created by Google, it's now owned by the Cloud Native Computing Foundation and developed in the Open Source model by developers from a host of companies, including Google, Red Hat, and Microsoft.
I've conducted penetration tests on Kubernetes clusters and have found that they can vary substantially in susceptibility to attacks. On the one hand, under-configured clusters like the one by Tesla that was hacked can require nothing more than a web browser to fully compromise.
Most Kubernetes clusters have a few weaknesses. Often, I can chain a few weaknesses together to get control of an application, vital data, or the cluster itself.
On the other extreme, are Kubernetes clusters that have been well hardened, making my job as an attacker very difficult.
One situation that's definitely more difficult for defenders anywhere in computing, but particularly in Kubernetes, is the "multitenant" configuration, where multiple departments in the same company (soft multitenancy), or perhaps multiple companies (hard multitenancy), are using the same cluster. In the soft multitenancy case, the different tenants may have differing threat models or risk appetites. In the hard multitenancy case, the tenants may actually be hostile to each other.
In my recent webinar, the second in my "Bust-a-Kube" Kubernetes hacking series, I demonstrated an attack on a soft multitenant Kubernetes cluster, compromising one tenant's application that runs with less privilege, before finding a path from that tenant to a more privileged one, and then using that privilege to compromise beyond the Kubernetes cluster. In the webinar, I also demonstrate a defense to stop one point in the attack chain and discuss several other cyber defenses. There's also an "Easter egg," an entertaining surprise at the end!
To learn more, be sure to check out the on-demand webinar: Kubernetes Hacking and Hardening Episode 2: Bust a Kube — and stay tuned for my upcoming white paper, where I’ll reveal additional strategies for defending Kubernetes clusters.
