Kubernetes Security - A Useful Bash One-Liner

Whether you’re an administrator, pentester, devop engineer, programmer, or some other IT person, chances are that you’ve heard of Kubernetes (k8s). If you’re a penetration tester like myself you may sometimes find yourself in odd situations involving k8s. One such situation is getting or being given super admin to a Kubernetes cluster, but you’re on a restricted network and can’t reach out to the internet to download and install third party tools to assist in your assessment. That is why I’m a fan of living off of the land when I can, and when it comes to K8s there’s no better tool than it’s very own kubectl.  Even without super god tier cluster admin rights, it’s an indispensable tool for working with Kubernetes from all perspectives; the builder, the defender, and like me the attacker.

In this post I’m going to briefly describe a simple bash script which leverages kubectl in order to dump as much raw YAML describing the cluster’s configuration as your current level of access will allow. This is particularly useful if you’re crunched for time, have already exhausted most attack paths, or want to see what else you can test out.

The Skinny on the Script 🧾

for res in $(kubectl api-resources -o name);do kubectl get $res -o yaml | tee -a k8s.dump;done

Look at it. Isn’t it cute? It’s just a simple bash one-liner made up of two kubectl commands and a pipe to tee for good measure. Okay, let me step back and explain what this short, sweet, and simple one liner is doing.  First the script calls the command below in the for loop condition.

kubectl api-resources -o name

The command above causes kubectl to reach out to the configured Kubernetes api and lists off all of the api-resources within the given cluster.  The result is a newline delimited list of names. Simple as that, no yaml, no json, just a flat list of names of goodies that the cluster api has to offer 🙂

In the body of the loop we have the following command which uses kubectl to get the description of each of the aforementioned api resources and outputs the results as YAML.

kubectl get $res -o yaml

Finally we pipe all of the output from the loop doing it’s thing into tee, a beautiful little command line utility if I do say so myself. This appends the output to a file named k8s.dump (If you’re immature like me, you probably giggle every time you read that file name) for analysis later.

tee -a k8s.dump

And that’s it! That’s all there is to it. Of course how much you get out of it will depend on what level of access you have to the cluster API, both from a permissions perspective and a network routing perspective. If you can’t route to the target Kuberenetes API server, then this isn’t going to be very helpful for you.

A Visual Feast For Your 👀

Below is a short video showing the usage of the script against an instance of my project called Arrrspace. It’s a work in progress vulnerable target app, meant to simulate a modern micro-services backed web application which is deployed on a Kubernetes cluster. PR’s are welcome, just beware that it’s in a rough state because, you know life and stuff. Alright, enough touting my own projects here’s the video.

In the video you can see the script going at it, spouting out a lot of information! That’s because Arrrspace is terribly insecure, so I basically had the keys to the kingdom from the get go. Once the script is done, you can see where I use the command – grep “token” -c k8s.dump – to search for any plain text secrets that might not be properly managed and ‘hidden’ away within the descriptions of the API resources. This is a perfect example of something that both penetration testers and administrators alike can do to find security risks within their cluster. Of course there are great tools out there for auditing one’s cluster as well, some of which will do the leg work of identifying some flaws for you.  However, at the end of the day being knowledgeable of the built-in and available commands on a system is a useful tool in any security professionals toolbelt, since these automation tools may not be available in a given situation and living off the land is the only way to go. Also, there’s no replacement for good old security professionals giving it a look over too, since relying on automated tools often cause false positive and false negative results and need to be hand validated anyway.

If you want you can find the script here in my infrequently updated and poorly documented repo called Harpoon 😀 You can also find me on Twitter @84d93r.