Kubectl is The New Root

What is Kubectl?

Kubectl is the new root. Kubectl is the primary CLI of the common online interface that Kubernetes provides by default, to interact with the Kubernetes API server. So it’s kind of a Swiss army knife. Everything you want to do with a Kubernetes Cluster or multiple Kubernetes Clusters you can do that on a common line using Kubectl. So when you first create a Kubernetes Cluster, it doesn’t matter whether it is on premises, using the basic Kubernetes tools, or you’re creating it using a managed provider like AWS, Azure, Google. So when you first create the Kubernetes cluster, they generate credentials that you basically plug in to Kubectl to interact with the cluster. So what ended up happening in most cases is that you’d do a POC, play with some workloads that you deploy to the cluster, you love the way Kubernetes is managing the workloads – and then move on to a staging environment or a test environment so you’ll create another cluster there. You then record new credentials for new clusters, you plug that into Kubectl, start using it and then down the line you decide to go into production. Again you created a new cluster, generated the credentials, put that into Kubectl, and moved on. 

So in this process the more and more clients I talk to I see that they make the basic mistake of not actually controlling, or putting the right controls around the credentials, that are generated by default by the clusters. Some clusters generate credentials that cannot be copied; it has to be the Kubectl which needs to be executed from a controlled environment — which is good – but most of them don’t do that because they want easy and quick adoption. So, they make the barrier to entry really low by creating a credential that is easy to use and has the most privileges. So as part of your production roll out — or even I’d suggest test roll out and staging roll out — you need to figure out how to control Kubectl and that means you need to control how to use the credentials that are generated by the cluster. Now there are several ways to do it, and you need to find the best practices, make sure that it is generated properly and handed over to the right people and you have a plan to keep the credentials rolling so that if it accidentally leaks it can easily be switched. Furthermore, the attack surface is not that bad when it comes to people getting ahold of your cluster; so that is something to think about since there are best practices around how to use the credentials and how to generate the credentials, and one of the things you want to start looking at is the role spaced access control – which is RBAC for short – so it is important to do that. This article is primarily meant to generate awareness on Kubectl and Kubectl is kind of a root by default, because of the default credentials and the privileges that it gets, so make sure that you have a plan to control it.