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
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
- 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
- Let's try to get Kubernetes cluster secrets from namespace
kube-system
:
$ kubectl get secrets -n kube-system
- 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
- Now when
pwnchart
deployed, the default service account has full administrative access. Let's check again getting secrets fromkube-system
kubectl get secrets -n kube-system
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