Павел Селиванов, архитект на решения Southbridge и преподавател по Slurm, изнесе лекция на DevOpsConf 2019. Тази лекция е част от една от темите на курса Slurm Mega за напреднали по Kubernetes.
се провежда в Москва на 18-20 ноември.
- Москва, 22-24 ноември.
винаги на разположение.
Под разреза - препис от доклада.
Добър ден, колеги и симпатизанти. Днес ще говоря за сигурността.
Виждам, че днес в залата има много хора от охраната. Предварително ви се извинявам, ако използвам термини от света на сигурността не съвсем както обикновено.
Случи се така, че преди около шест месеца един публичен клъстер Kubernetes падна в ръцете ми. Публично - означава, че има n-ти брой пространства от имена, в тези пространства от имена има потребители, изолирани в тяхното пространство от имена. Всички тези потребители принадлежат на различни компании. Е, предполагаше се, че този клъстер трябва да се използва като CDN. Тоест, те ви дават клъстер, дават потребител там, вие отивате там във вашето пространство от имена, разгръщате вашите фронтове.
Предишната ми фирма се опита да продаде такава услуга. И ме помолиха да бръкна в клъстера по темата - дали такова решение е подходящо или не.
Стигнах до този клъстер. Дадоха ми ограничени права, ограничено пространство на имената. Там момчетата разбраха какво е сигурност. Те прочетоха какво е Role-based access control (RBAC) в Kubernetes - и го изкривиха така, че да не мога да стартирам pods отделно от внедряванията. Не си спомням проблема, който се опитвах да разреша, като стартирах pod без внедряване, но наистина исках да стартирам само pod. Реших за късмет да видя какви права имам в клъстера, какво мога, какво не мога, какво са прецакали там. В същото време ще ви кажа какво са конфигурирали неправилно в RBAC.
Случи се така, че за две минути получих администратор на техния клъстер, разгледах всички съседни пространства от имена, видях производствените фронтове на компании, които вече бяха закупили услугата и се разположиха там. Едвам се сдържах да не дойда при някой отпред и да пусна някакви псувни на главната страница.
Ще ви кажа с примери как го направих и как да се защитя срещу него.
Но първо нека се представя. Казвам се Павел Селиванов. Аз съм архитект за Southbridge. Разбирам Kubernetes, DevOps и всякакви фантастични неща. Инженерите на Southbridge и аз изграждаме всичко и аз се консултирам.
В допълнение към основните ни дейности, наскоро стартирахме проекти, наречени Slurms. Опитваме се да донесем малко способността си да работим с Kubernetes на масите, за да научим и други хора как да работят с K8s.
За какво ще говоря днес. Темата на доклада е очевидна - за сигурността на клъстера Kubernetes. Но искам веднага да кажа, че тази тема е много голяма - и затова искам веднага да уточня за какво определено няма да говоря. Няма да говоря за изтъркани термини, които вече са били използвани сто пъти в интернет. Всички RBAC и сертификати.
Ще говоря за това, което ме боли и моите колеги от сигурността в един Kubernetes клъстер. Виждаме тези проблеми както при доставчиците, които предоставят клъстери на Kubernetes, така и при клиентите, които идват при нас. И дори за клиенти, които идват при нас от други консултантски административни компании. Тоест мащабът на трагедията всъщност е много голям.
Буквално три точки, за които ще говоря днес:
- Права на потребител срещу права на pod. Потребителските права и правата на pod не са едно и също нещо.
- Събиране на информация за клъстера. Ще покажа, че можете да събирате цялата необходима информация от клъстер, без да имате специални права в този клъстер.
- DoS атака на клъстера. Ако не успеем да съберем информация, ще можем да поставим клъстера във всеки случай. Ще говоря за DoS атаки върху контролни елементи на клъстера.
Друго общо нещо, което ще спомена, е върху какво го тествах, за което мога да кажа със сигурност, че всичко работи.
Като основа вземаме инсталирането на Kubernetes клъстер с помощта на Kubespray. Ако някой не знае, това всъщност е набор от роли за Ansible. Използваме го през цялото време на работа. Хубавото е, че можеш да се търкаляш навсякъде – и по железните парчета, и някъде в облака. Един метод на инсталиране е подходящ по принцип за всичко.
В този клъстер ще имам Kubernetes v1.14.5. Целият клъстер Cube, който ще разгледаме, е разделен на пространства от имена, всяко пространство от имена принадлежи на отделен екип, членовете на този екип имат достъп до всяко пространство от имена. Те не могат да отидат в различни пространства от имена, а само в собствените си. Но има определен администраторски акаунт, който има права върху целия клъстер.
Обещах, че първото нещо, което ще имаме, е да получим администраторски права за клъстера. Имаме нужда от специално подготвена капсула, която ще разбие клъстера Kubernetes. Всичко, което трябва да направим, е да го приложим към клъстера Kubernetes.
kubectl apply -f pod.yamlТази капсула ще дойде при един от майсторите на клъстера Kubernetes. И клъстерът с радост ще върне файл, наречен admin.conf след това. В Куба този файл съхранява всички администраторски сертификати и в същото време API на клъстера е конфигуриран. Ето колко лесно е да получите администраторски достъп, според мен, до 98% от клъстерите на Kubernetes.
Отново, тази група е направена от един разработчик във вашия клъстер, който има достъп до внедряване на своите предложения в едно малко пространство от имена, всичките той е ограничен от RBAC. Той нямаше никакви права. Но въпреки това сертификатът се върна.
А сега за специално подготвено огнище. Стартираме на всяко изображение. Нека вземем debian:jessie като пример.
Имаме нещо подобно:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Какво е толерантност? Мастерите в клъстер на Kubernetes обикновено са етикетирани с нещо, наречено taint. И същността на тази „инфекция“ е, че казва, че pods не могат да бъдат присвоени на главни възли. Но никой не си прави труда да посочи във всяка капсула, че е толерантен към „инфекцията“. Разделът за толерантност просто казва, че ако NoSchedule е инсталиран на някакъв възел, тогава нашият модул е толерантен към такава инфекция - и няма проблеми.
Освен това казваме, че нашата шушулка е не само толерантна, но и иска да удари господаря нарочно. Защото майсторите имат най-вкусното, което ни трябва - всички сертификати. Затова казваме nodeSelector - и имаме стандартен етикет на главните, който ви позволява да изберете от всички възли на клъстера точно тези възли, които са главни.
С тези две секции определено ще дойде при майстора. И ще му бъде позволено да живее там.
Но само да дойдем при майстора не ни е достатъчно. Нищо няма да ни даде. След това имаме тези две неща:
hostNetwork: true
hostPID: true Уточняваме, че нашият pod, който изпълняваме, ще живее в пространството от имена на ядрото, пространството от имена на мрежата и пространството от имена на PID. След като под стартира на главния, той ще може да вижда всички реални, живи интерфейси на този възел, да слуша целия трафик и да вижда PID на всички процеси.
Тогава всичко зависи от малките неща. Вземете etcd и прочетете каквото искате.
Най-интересното нещо е тази функция на Kubernetes, която е там по подразбиране.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host И същността му е, че можем в под, който стартираме, дори без права върху този клъстер, да кажем, че искаме да създадем обем от типа hostPath. Така че вземете пътя от хоста, от който ще започнем - и го приемете като обем. И тогава го наричаме име: хост. Ние монтираме целия този hostPath вътре в pod. В този пример към директорията /host.
Още веднъж ще повторя. Казахме на пода да дойде при главния, да получи hostNetwork и hostPID там - и да монтира целия корен на главния вътре в този под.
Разбирате, че в debian работи bash и този bash работи за нас като root. Тоест, ние просто получихме root на главния, без да имаме никакви права в клъстера Kubernetes.
След това цялата задача е да отидете в директорията / host / etc / kubernetes / pki, ако не греша, да вземете всички главни сертификати на клъстера там и съответно да станете администратор на клъстера.
Погледнато по този начин, това са някои от най-опасните права в pods, независимо какви права има потребителят:
Ако имам права да стартирам под в някакво пространство от имена на клъстер, тогава този под има тези права по подразбиране. Мога да стартирам привилегировани pods, което обикновено е с всички права, на практика руутване на възел.
Моят любим е Root user. И Kubernetes има тази опция Run As Non-Root. Това е вид защита срещу хакер. Знаете ли какво е „молдовският вирус“? Ако внезапно сте хакер и сте стигнали до моя клъстер Kubernetes, тогава ние, бедните администратори, питаме: „Моля, посочете във вашите подове, с които ще хакнете моя клъстер, стартирайте като не-root. В противен случай ще се окаже, че стартирате процеса във вашия pod под root и ще бъде много лесно за вас да ме хакнете. Защитете се, моля."
Обем на пътя на хоста - според мен най-бързият начин да получите желания резултат от клъстера Kubernetes.
Но какво да правим с всичко това?
Мисли, които трябва да дойдат на всеки нормален администратор, който се сблъска с Kubernetes: „Да, казах ви, Kubernetes не работи. Има дупки в него. И целият Куб е глупост. Всъщност има такова нещо като документация и ако погледнете там, значи има раздел .
Това е такъв yaml обект - можем да го създадем в клъстера Kubernetes - който контролира аспектите на сигурността в описанието на pods. Тоест всъщност той контролира правата за използване на която и да е хост мрежа, хостPID, определени типове томове, които са в подовете при стартиране. С помощта на Pod Security Policy всичко това може да бъде описано.
Най-интересното в политиката за сигурност на Pod е, че в клъстера Kubernetes всички инсталатори на PSP не просто не са описани по никакъв начин, те просто са изключени по подразбиране. Политиката за сигурност на Pod е активирана с помощта на приставката за достъп.
Добре, нека разположим Pod Security Policy към клъстера, да кажем, че имаме някои сервизни pods в пространството на имената, до които само администраторите имат достъп. Да кажем, във всичко останало подс. Тъй като най-вероятно разработчиците не трябва да изпълняват привилегировани подове на вашия клъстер.
И май сме добре. И нашият Kubernetes клъстер не може да бъде хакнат за две минути.
Има проблем. Най-вероятно, ако имате клъстер Kubernetes, тогава мониторингът е инсталиран във вашия клъстер. Дори се ангажирам да предскажа, че ако вашият клъстер има мониторинг, тогава той се нарича Прометей.
Това, което ще ви кажа сега, ще важи както за оператора Prometheus, така и за Prometheus, доставен в чист вид. Въпросът е, че ако не мога да намеря администратор на клъстера толкова бързо, това означава, че трябва да търся повече. И мога да търся, използвайки вашето наблюдение.
Вероятно всички четат едни и същи статии на Habré и мониторингът се намира в пространството за наблюдение на имената. Диаграмата на кормилото се нарича приблизително еднакво за всички. Предполагам, че ако инсталирате helm stable/prometheus, трябва да получите приблизително същите имена. И дори най-вероятно няма да се налага да отгатвам DNS името във вашия клъстер. Защото е стандартно.
След това имаме определен dev ns, в който можете да стартирате определен pod. И след това от тази капсула е много лесно да направите следното:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics е един от износителите на prometheus, който събира показатели от самия Kubernetes API. Там има много данни, какво работи във вашия клъстер, какво е, какви проблеми имате с него.
Като прост пример:
kube_pod_container_info{namespace="kube-system",pod="kube-apiserver-k8s-1",container="kube-apiserver",image=
"gcr.io/google-containers/kube-apserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Като направите проста заявка за къдряне от непривилегирован под, можете да получите информация като тази. Ако не знаете каква версия на Kubernetes използвате, тя лесно ще ви каже.
И най-интересното е, че в допълнение към факта, че имате достъп до kube-state-metrics, можете също така да получите директен достъп до самия Prometheus. Можете да събирате показатели от там. Можете дори да изградите показатели от там. Дори теоретично можете да изградите такава заявка от клъстер в Prometheus, която просто ще го изключи. И вашето наблюдение като цяло ще спре да работи от клъстера.
И тук вече възниква въпросът дали някакъв външен мониторинг следи вашия мониторинг. Току-що получих възможността да работя в клъстер на Kubernetes без никакви последствия за себе си. Дори няма да разберете, че работя там, тъй като вече няма наблюдение.
Точно както при PSP, изглежда, че проблемът е, че всички тези фантастични технологии - Kubernetes, Prometheus - просто не работят и са пълни с дупки. Не точно.
Има такова нещо - .
Ако сте нормален администратор, тогава най-вероятно знаете за мрежовата политика, че това е друг yaml, от който вече има dofiga в клъстера. И мрежовите политики определено не са необходими. И дори ако прочетете какво е мрежова политика, какво е защитна стена на yaml на Kubernetes, тя ви позволява да ограничите правата за достъп между пространства от имена, между подове, тогава определено сте решили, че защитната стена на yaml в Kubernetes се основава на следващите абстракции ... Не - не . Определено не е необходимо.
Дори ако на вашите специалисти по сигурността не е казано, че с помощта на вашия Kubernetes можете да изградите много лесна и проста защитна стена и много подробна. Ако те все още не знаят това и не ви дърпат: „Е, дай го, дай го ...“ Тогава във всеки случай се нуждаете от мрежова политика, за да блокирате достъпа до някои места за услуги, които можете да изтеглите от вашия клъстер без никакво разрешение.
Както в примера, който дадох, можете да изтеглите показатели за състоянието на kube от всяко пространство на имена в клъстера Kubernetes, без да имате никакви права за това. Мрежовите политики са затворили достъпа от всички други пространства от имена до пространството от имена за мониторинг и, така да се каже, всичко: няма достъп, няма проблеми. Във всички диаграми, които съществуват, както в стандартния прометей, така и в прометей, който е в оператора, има просто опция в стойностите на кормилото просто да активирате мрежовите политики за тях. Просто трябва да го включите и те ще работят.
Тук наистина има един проблем. Като нормален брадат администратор най-вероятно сте решили, че мрежовите политики не са необходими. И след като прочетете всякакви статии за ресурси като Habr, решихте, че фланелът, особено с режима на хост-шлюз, е най-доброто нещо, което можете да изберете.
Какво да правя?
Можете да опитате да преразположите мрежовото решение, което имате във вашия клъстер Kubernetes, опитайте се да го замените с нещо по-функционално. На същия Calico, например. Но веднага искам да кажа, че задачата за промяна на мрежовото решение в работещия клъстер Kubernetes е доста нетривиална. Реших го два пъти (и двата пъти обаче теоретично), но дори показахме как се прави в Slurms. На нашите студенти показахме как да променят мрежовото решение в клъстер на Kubernetes. По принцип можете да опитате да се уверите, че няма прекъсване на производствения клъстер. Но най-вероятно няма да успеете.
И проблемът всъщност се решава много просто. Има сертификати в клъстера и знаете, че вашите сертификати ще се повредят след една година. Е, и обикновено нормално решение със сертификати в клъстера - защо ще вземем парна баня, ще вдигнем нов клъстер до него, ще го оставим да се развали в стария и ще преразпределим всичко. Вярно, че като изгние, всичко ще лежи за един ден, но след това нов клъстер.
Когато издигате нов клъстер, в същото време вмъкнете Calico вместо фланела.
Какво да направите, ако имате издадени сертификати за сто години и няма да преразпределите клъстера? Има такова нещо Kube-RBAC-Proxy. Това е много готина разработка, позволява ви да се вградите като контейнер с количка към всяка капсула в клъстер на Kubernetes. И всъщност добавя оторизация чрез RBAC на самия Kubernetes към тази група.
Има един проблем. Преди това решението Kube-RBAC-Proxy беше вградено в prometheus на оператора. Но после го нямаше. Сега модерните версии разчитат на факта, че имате мрежови политики и ги затваряте с тях. И така, трябва малко да пренапишете диаграмата. Всъщност, ако отидете на , има примери за това как да го използвате като странични коли и графиките ще трябва да бъдат пренаписани минимално.
Има още един малък проблем. Не само Prometheus раздава своите показатели на никого. В нашия случай всички компоненти на клъстера Kubernetes също могат да дадат своите показатели.
Но както казах, ако не можете да получите достъп до клъстера и да съберете информация, тогава можете поне да навредите.
Така че бързо ще ви покажа два начина, по които един Kubernetes клъстер може да се разболее.
Ще се смеете, когато ви кажа, че това са два реални случая.
Метод първи. Изчерпване на ресурсите.
Пускаме още една специална капсула. Ще има този раздел.
resources:
requests:
cpu: 4
memory: 4Gi Както знаете, заявките са количеството процесор и памет, които са запазени на хоста за конкретни заявки. Ако имаме четириядрен хост в клъстера на Kubernetes и там пристигнат четири процесорни капсули със заявки, тогава повече капсули със заявки не могат да дойдат до този хост.
Ако стартирам такъв pod, издавам командата:
$ kubectl scale special-pod --replicas=...Тогава никой друг няма да може да се внедри в клъстера Kubernetes. Тъй като всички възли ще изчерпят заявките. И така ще спра вашия клъстер Kubernetes. Ако направя това вечер, тогава внедряванията могат да бъдат спрени за доста дълго време.
Ако погледнем отново документацията на Kubernetes, ще видим такова нещо, наречено Limit Range. Той задава ресурсите за обектите на клъстера. Можете да напишете обект Limit Range в yaml, да го приложите към определени пространства от имена - и по-нататък в това пространство от имена можете да кажете, че имате ресурси за подразбиращи се, максимални и минимални подове.
С помощта на такова нещо можем да ограничим потребителите в конкретни пространства от имена на екипни продукти от възможността да посочват всякакви неприятни неща в своите подове. Но за съжаление, дори ако кажете на потребителя, че не можете да стартирате pods със заявки за повече от един процесор, има такава чудесна команда за мащабиране, добре, или чрез таблото за управление те могат да направят мащаб.
И тук идва номер две. Изпълнение 11 111 111 111 111 подс. Това са единадесет милиарда. Това не е защото съм измислил такъв номер, а защото сам го видях.
Истинска история. Късно вечерта се канех да излизам от офиса. Гледам, група разработчици седят в ъгъла и трескаво правят нещо с лаптопи. Отивам при момчетата и питам: „Какво се случи с вас?“
Малко по-рано, в девет часа вечерта, един от разработчиците се прибираше вкъщи. И реших: „Сега ще мащабирам приложението си до едно.“ Натиснах едно и интернета малко се затъпи. Той натисна отново едното, натисна едното, натисна Enter. Той мушна всичко, което можеше. Тогава Интернет оживя - и всичко започна да се мащабира до тази дата.
Вярно, тази история не се случи на Kubernetes, по това време беше Nomad. Завърши с факта, че след един час опити да спрем Nomad от упорити опити за мащабиране, Nomad отговори, че няма да спре мащабирането и няма да прави нищо друго. — Уморен съм, тръгвам си. И се обърна.
Естествено се опитах да направя същото на Kubernetes. Единадесет милиарда шушулки Kubernetes не хареса, той каза: „Не мога. Надвишава вътрешните капачки. Но 1 000 000 000 шушулки биха могли.
В отговор на един милиард, Кубът не се оттегли в себе си. Той наистина започна да се мащабира. Колкото по-напред вървеше процесът, толкова повече време отнемаше създаването на нови капсули. Но все пак процесът продължи. Единственият проблем е, че ако мога да стартирам pods в моето пространство от имена за неопределено време, тогава дори без заявки и ограничения, мога да стартирам такъв брой pods с някои задачи, че с помощта на тези задачи възлите ще започнат да се събират от паметта, на процесора. Когато стартирам толкова много подове, информацията от тях трябва да влезе в хранилището, т.е. и т.н. И когато постъпи твърде много информация, хранилището започва да се връща твърде бавно - и Kubernetes започва да става тъп.
И още един проблем ... Както знаете, контролите на Kubernetes не са някакво централно нещо, а няколко компонента. Там по-специално има мениджър на контролер, планировчик и т.н. Всички тези момчета ще започнат да вършат ненужна глупава работа едновременно, която с времето ще започне да отнема все повече и повече време. Мениджърът на контролера ще създаде нови подове. Планировчикът ще се опита да намери нов възел за тях. Новите възли във вашия клъстер най-вероятно ще свършат скоро. Клъстерът Kubernetes ще започне да работи все по-бавно и по-бавно.
Но реших да отида още по-далеч. Както знаете, Kubernetes има нещо, наречено услуга. Е, по подразбиране във вашите клъстери най-вероятно услугата работи с IP таблици.
Ако стартирате един милиард подове, например, и след това използвате скрипт, за да принудите Kubernetis да създаде нови услуги:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Във всички възли на клъстера все повече нови правила за iptables ще се генерират приблизително едновременно. Освен това, един милиард iptables правила ще бъдат генерирани за всяка услуга.
Проверих цялото това нещо на няколко хиляди, до дузина. И проблемът е, че вече при този праг е доста проблематично да се направи ssh към възела. Защото пакетите, преминавайки през толкова много вериги, започват да не се чувстват много добре.
И това също е решено с помощта на Kubernetes. Има такъв обект Ресурсна квота. Задава броя на наличните ресурси и обекти за пространството от имена в клъстера. Можем да създадем yaml обект във всяко пространство от имена на клъстер на Kubernetes. С помощта на този обект можем да кажем, че имаме определен брой заявки, ограничения, разпределени за това пространство от имена, и освен това можем да кажем, че е възможно да създадем 10 услуги и 10 pods в това пространство от имена. И един разработчик дори може да се смачка вечер. Kubernetes ще му каже: „Не можете да мащабирате подовете си до такава сума, защото надвишава квотата за ресурси.“ Това е, проблемът е решен. .
Във връзка с това възниква един проблем. Усещате колко трудно става създаването на пространство от имена в Kubernetes. За да го създадем, трябва да вземем предвид куп неща.
Ресурсна квота + Ограничен диапазон + RBAC
• Създайте пространство от имена
• Създайте вътрешен лимитиран диапазон
• Създайте вътрешна квота за ресурси
• Създайте сервизен акаунт за CI
• Създайте rolebinding за CI и потребители
• По желание стартирайте необходимите сервизни модули
Затова, използвайки случая, бих искал да споделя моите разработки. Има такова нещо, наречено SDK оператор. Това е начинът в клъстера Kubernetes да пишат изрази за него. Можете да пишете изявления с Ansible.
Първоначално писахме на Ansible, а след това погледнах какво представлява SDK операторът и пренаписах ролята на Ansible в оператор. Този оператор ви позволява да създадете обект в клъстера Kubernetes, наречен команда. Вътре в командата ви позволява да опишете в yaml средата за тази команда. И вътре в екипната среда ни позволява да опишем, че разпределяме толкова много ресурси.
дребничка .
И в заключение. Какво да правим с всичко това?
Първо. Политиката за сигурност на Pod е добра. И въпреки факта, че никой от инсталаторите на Kubernetes не ги използва до ден днешен, все още трябва да ги използвате във вашите клъстери.
Мрежовата политика не е някаква друга ненужна функция. Това е, което наистина е необходимо в клъстера.
LimitRange / ResourceQuota - време е да използвате. Започнахме да го използваме преди много време и дълго време бях сигурен, че всички без изключение го използват. Оказа се, че това е рядкост.
В допълнение към това, което споменах по време на доклада, има недокументирани функции, които ви позволяват да атакувате клъстера. Издадена наскоро .
Някои неща са толкова тъжни и болезнени. Например, при определени условия, кубелети в клъстер на Kubernetes могат да предоставят съдържанието на директорията на магьосниците и на неоторизиран потребител.
има инструкции как да възпроизведете всичко, което казах. Има файлове с примери за производство, как изглежда ResourceQuota, Pod Security Policy. И всичко това може да се пипне.
Благодаря на всички.
Източник: www.habr.com