Helm — menedżer pakietów dla Kubernetes, coś w rodzaju apt-get dla Ubuntu. W tej notatce zobaczymy wcześniejszą wersję helm (v2) z domyślnie zainstalowanym serwisem tiller, przez który uzyskamy dostęp do klastra.
Przygotujmy klaster, w tym celu uruchomimy polecenie:
kubectl run --rm --restart=Never -it --image=madhuakula/k8s-goat-helm-tiller -- bash
Demonstracja
- Jeśli nie dokonamy dodatkowych ustawień, helm v2 uruchamia serwis tiller, który ma RBAC z pełnymi uprawnieniami administratora klastra.
- Po zainstalowaniu w namespace
kube-systempojawia siętiller-deploy, otwierany jest także port 44134, przypisany do 0.0.0.0. Można to sprawdzić za pomocą telnet.
$ telnet tiller-deploy.kube-system 44134
- Teraz możemy połączyć się z serwisem tiller. Będziemy używać binarki helm do przeprowadzania operacji przy komunikacji z serwisem tiller:
$ helm --host tiller-deploy.kube-system:44134 version
- Spróbujemy uzyskać sekrety klastra Kubernetes z namespace
kube-system:
$ kubectl get secrets -n kube-system
- Teraz możemy stworzyć własny chart, w którym stworzymy rolę z uprawnieniami administratora i przypiszemy tę rolę domyślnemu kontu serwisowemu. Używając tokena od tego konta serwisowego, uzyskaliśmy pełen dostęp do naszego klastra.
$ helm --host tiller-deploy.kube-system:44134 install /pwnchart
- Teraz, gdy
pwnchartzostał wdrożony, domyślne konto serwisowe ma pełny dostęp administracyjny. Sprawdźmy jeszcze raz uzyskiwanie sekretów zkube-system
kubectl get secrets -n kube-system
Sukces tego scenariusza zależy od tego, jak został wdrożony tiller, czasami administratorzy wdrażają go w osobnym namespace z innymi uprawnieniami. Helm 3 nie jest podatny na takie luki, ponieważ nie zawiera tillera.
Uwaga tłumacza: użycie polityk sieciowych do filtrowania ruchu w klastrze pomaga zabezpieczyć się przed tego typu lukami.
Źródło: habr.com
