
Helm — gestore di pacchetti per Kubernetes, qualcosa di simile apt-get per Ubuntu. In questa nota vedremo la versione precedente di helm (v2) con il servizio tiller installato di default, tramite il quale accederemo al cluster.
Prepariamo il cluster, per questo eseguiamo il comando:
kubectl run --rm --restart=Never -it --image=madhuakula/k8s-goat-helm-tiller -- bash![]()
Dimostrazione
- Se non si configura nulla in aggiunta, helm v2 avvia il servizio tiller, che ha RBAC con pieni diritti amministrativi sul cluster.
- Dopo l'installazione nel namespace
kube-systemvienetiller-deploy, viene inoltre aperta la porta 44134, collegata a 0.0.0.0. Questo può essere verificato utilizzando telnet.
$ telnet tiller-deploy.kube-system 44134
- Ora possiamo connetterci al servizio tiller. Useremo il binario helm per eseguire operazioni durante la comunicazione con il servizio tiller:
$ helm --host tiller-deploy.kube-system:44134 version![]()
- Proviamo a ottenere i segreti del cluster Kubernetes dal namespace
kube-system:
$ kubectl get secrets -n kube-system![]()
- Ora possiamo creare il nostro grafico, in cui creeremo un ruolo con diritti di amministratore e assegneremo questo ruolo all'account di servizio predefinito. Utilizzando il token di questo account di servizio, abbiamo ottenuto accesso completo al nostro cluster.
$ helm --host tiller-deploy.kube-system:44134 install /pwnchart
- Ora che
pwnchartè stato distribuito, l'account di servizio predefinito ha accesso amministrativo completo. Verifichiamo di nuovo l'ottenimento dei segreti dakube-system
kubectl get secrets -n kube-system
Il successo di questo scenario dipende da come è stato distribuito tiller, a volte gli amministratori lo distribuiscono in un namespace separato con altre autorizzazioni. Helm 3 non è soggetto a tali vulnerabilità, poiché non contiene tiller.
Nota del traduttore: l'uso di politiche di rete per filtrare il traffico nel cluster aiuta a proteggersi da vulnerabilità di questo tipo.
Fonte: habr.com
