Breaking a Kubernetes Cluster with Helm v2 tiller

Breaking a Kubernetes Cluster with Helm v2 tiller

Helm is a package manager for Kubernetes, something like apt-get for Ubuntu. In this note, we will see the previous version of helm (v2) with the tiller service installed by default, through which we will access the cluster.

Let's prepare the cluster, for this we will run the command:

kubectl run --rm --restart=Never -it --image=madhuakula/k8s-goat-helm-tiller -- bash

Breaking a Kubernetes Cluster with Helm v2 tiller

Demonstration

  • If nothing else is configured, helm v2 starts the tiller service, which has RBAC with full cluster administrator rights.
  • After setting in namespace kube-system появляСтся tiller-deploy, and also opens port 44134 bound to 0.0.0.0. This can be checked with telnet.

$ telnet tiller-deploy.kube-system 44134

Breaking a Kubernetes Cluster with Helm v2 tiller

  • Now you can connect to the tiller service. We will use the helm binary to perform operations when communicating with the tiller service:

$ helm --host tiller-deploy.kube-system:44134 version

Breaking a Kubernetes Cluster with Helm v2 tiller

  • Let's try to get Kubernetes cluster secrets from namespace kube-system:

$ kubectl get secrets -n kube-system

Breaking a Kubernetes Cluster with Helm v2 tiller

  • Now we can create our own chart, in which we will create a role with administrator rights and assign this role to the default service account. Using the token from this service account, we got full access to our cluster.

$ helm --host tiller-deploy.kube-system:44134 install /pwnchart

Breaking a Kubernetes Cluster with Helm v2 tiller

  • Now when pwnchart deployed, the default service account has full administrative access. Let's check again getting secrets from kube-system

kubectl get secrets -n kube-system

Breaking a Kubernetes Cluster with Helm v2 tiller

The success of this scenario depends on how tiller was deployed, sometimes administrators deploy it in a separate namespace with different privileges. Helm 3 is not affected by such vulnerabilities, because. there is no tiller in it.

Translator's Note: using network policies to filter traffic in a cluster helps protect against these types of vulnerabilities.

Source: habr.com

Add a comment