
Helm ā een pakketbeheerder voor Kubernetes, iets vergelijkbaars apt-get met Ubuntu. In dit artikel bekijken we de vorige versie van helm (v2) met de standaard geĆÆnstalleerde tiller-service, waarmee we toegang krijgen tot het cluster.
Laten we het cluster voorbereiden, hiervoor voeren we het volgende commando uit:
kubectl run --rm --restart=Never -it --image=madhuakula/k8s-goat-helm-tiller -- bash![]()
Demonstratie
- Als er verder niets wordt ingesteld, start helm v2 de tiller-service, die RBAC met volledige administratieve rechten voor het cluster heeft.
- Na de installatie in de namespace
kube-systemverschijnttiller-deploy, wordt ook poort 44134 geopend, verbonden met 0.0.0.0. Dit kan worden gecontroleerd met telnet.
$ telnet tiller-deploy.kube-system 44134
- Nu kunnen we verbinding maken met de tiller-service. We zullen de helm-binary gebruiken voor operaties tijdens de communicatie met de tiller-service:
$ helm --host tiller-deploy.kube-system:44134 version![]()
- Laten we proberen de geheimen van het Kubernetes-cluster op te halen uit de namespace
kube-system:
$ kubectl get secrets -n kube-system![]()
- Nu kunnen we onze eigen chart maken, waarin we een rol met administratieve rechten creƫren en deze rol toewijzen aan het standaard serviceaccount. Met de token van dit serviceaccount hebben we volledige toegang tot ons cluster.
$ helm --host tiller-deploy.kube-system:44134 install /pwnchart
- Nu, wanneer
pwnchartis uitgerold, heeft het standaard serviceaccount volledige administratieve toegang. Laten we nogmaals de geheimen ophalen uitkube-system
kubectl get secrets -n kube-system
Het succes van dit scenario hangt af van hoe tiller is uitgerold, soms rollen beheerders het uit in een aparte namespace met andere privileges. Helm 3 is niet onderhevig aan dergelijke kwetsbaarheden, omdat het geen tiller bevat.
Opmerking van de vertaler: het gebruik van netwerkpolicies om verkeer in het cluster te filteren helpt te beschermen tegen dit soort kwetsbaarheden.
Bron: habr.com
