
Helm — пакетен мениджър за Kubernetes, нещо като apt-get за Ubuntu. В този бележка ще разгледаме предишната версия helm (v2) с инсталиран по подразбиране сервиз tiller, чрез който ще получим достъп до клъстера.
Да подготвим клъстера, за целта ще стартираме командата:
kubectl run --rm --restart=Never -it --image=madhuakula/k8s-goat-helm-tiller -- bash![]()
Демонстрация
- Ако не се настройва нищо допълнително, helm v2 стартира сервиз tiller, който има RBAC с пълни права на администратор на клъстера.
- След инсталация в namespace
kube-systemпоявяваtiller-deploy, също така се отваря порт 44134, свързан към 0.0.0.0. Това може да се провери с помощта на telnet.
$ telnet tiller-deploy.kube-system 44134
- Сега можем да се свържем със сервиза tiller. Ще използваме бинарния файл helm за извършване на операции при комуникация със сервиза tiller:
$ helm --host tiller-deploy.kube-system:44134 version![]()
- Нека опитаме да получим тайните на клъстера Kubernetes от namespace
kube-system:
$ kubectl get secrets -n kube-system![]()
- Сега можем да създадем собствен чарт, в който ще създадем роля с права на администратор и ще назначим тази роля на подразбиращия се сервизен акаунт. Използвайки токена от този сервизен акаунт, получихме пълен достъп до нашия клъстер.
$ helm --host tiller-deploy.kube-system:44134 install /pwnchart
- В момента, когато
pwnchartе разположен, сервизният акаунт по подразбиране има пълен административен достъп. Нека проверим отново получаването на тайните отkube-system
kubectl get secrets -n kube-system
Успешното изпълнение на този сценарий зависи от това как е разположен tiller, понякога администраторите го разполагат в отделен namespace с други привилегии. Helm 3 не е подложен на такива уязвимости, тъй като в него няма tiller.
Забележка на преводача: използването на мрежови политики за филтриране на трафика в клъстера помага да се защитим от подобни уязвимости.
Източник: habr.com
