Павел Селиванов, архитекта Соутхбридге решења и наставник Слурм-а, одржао је презентацију на ДевОпсЦонф 2019. Овај говор је део једне од тема детаљног курса о Кубернетесу „Слурм Мега“.
одржава се у Москви од 18. до 20. новембра.
— Москва, 22-24 новембар.
увек на располагању.
Испод реза је транскрипт извештаја.
Добар дан, колеге и они који их саосећају. Данас ћу говорити о безбедности.
Видим да је данас много обезбеђења у сали. Унапред се извињавам ако користим термине из света безбедности не баш онако како је вама уобичајено.
Десило се да сам пре отприлике шест месеци наишао на један јавни Кубернетес кластер. Јавно значи да постоји н-ти број именских простора; у тим именским просторима постоје корисници изоловани у њиховом именском простору. Сви ови корисници припадају различитим компанијама. Па, претпостављало се да овај кластер треба да се користи као ЦДН. То јест, дају вам кластер, дају вам корисника тамо, одете тамо у свој простор имена, поставите своје фронтове.
Моја претходна компанија је покушала да прода такву услугу. И замолили су ме да прободем кластер да видим да ли је ово решење прикладно или не.
Дошао сам у овај кластер. Добио сам ограничена права, ограничен простор имена. Тамо су момци схватили шта је безбедност. Прочитали су о контроли приступа заснованој на улогама (РБАЦ) у Кубернетес-у - и изврнули су је тако да нисам могао да покрећем подове одвојено од имплементација. Не сећам се проблема који сам покушавао да решим покретањем модула без постављања, али сам заиста желео да покренем само под. За срећу, одлучио сам да видим која права имам у кластеру, шта могу, шта не могу и шта су ту зезнули. У исто време, рећи ћу вам шта су погрешно конфигурисали у РБАЦ-у.
Десило се да сам за два минута примио администратора у њихов кластер, погледао све суседне просторе имена, видео тамо покренуте производне фронтове компанија које су већ купиле услугу и примениле је. Једва сам могао да се спречим да одем до нечијег фронта и ставим неку псовку на главну страницу.
Рећи ћу вам на примерима како сам то урадио и како да се заштитите од овога.
Али прво, дозволите ми да се представим. Моје име је Павел Селиванов. Ја сам архитекта у Соутхбридгеу. Разумем Кубернетес, ДевОпс и све врсте фенси ствари. Инжењери са Соутхбридге-а и ја градимо све ово, а ја консултујем.
Поред наших основних активности, недавно смо покренули пројекте под називом Слурмс. Покушавамо да своју способност да радимо са Кубернетес-ом мало приближимо масама, да научимо друге људе да такође раде са К8с.
О чему ћу данас причати? Тема извештаја је очигледна – о безбедности Кубернетес кластера. Али одмах желим да кажем да је ова тема веома велика - и зато желим одмах да разјасним о чему дефинитивно нећу говорити. Нећу да говорим о излуђеним терминима који су већ сто пута коришћени на интернету. Све врсте РБАЦ-а и сертификата.
Говорићу о томе шта мене и моје колеге боли у вези са сигурношћу у Кубернетес кластеру. Ове проблеме видимо и међу провајдерима који обезбеђују Кубернетес кластере и међу клијентима који долазе код нас. Па чак и од клијената који нам долазе из других консултантских административних компанија. Односно, размере трагедије су заправо веома велике.
Постоје буквално три тачке о којима ћу данас говорити:
- Корисничка права наспрам права под. Корисничка права и под права нису иста ствар.
- Прикупљање информација о кластеру. Показаћу вам да можете прикупити све информације које су вам потребне из кластера без посебних права у овом кластеру.
- ДоС напад на кластер. Ако не можемо да прикупимо информације, у сваком случају ћемо моћи да ставимо кластер. Говорићу о ДоС нападима на елементе контроле кластера.
Још једна општа ствар коју ћу поменути је на чему сам све ово тестирао, на чему са сигурношћу могу рећи да све функционише.
Као основу узимамо инсталацију Кубернетес кластера користећи Кубеспраи. Ако неко не зна, ово је заправо скуп улога за Ансибле. Константно га користимо у свом раду. Добра ствар је што можете да га котрљате било где - можете га намотати на комаде гвожђа или негде у облак. Једна метода инсталације у принципу функционише за све.
У овом кластеру ћу имати Кубернетес в1.14.5. Цео Цубе кластер, који ћемо размотрити, подељен је на просторе имена, сваки именски простор припада посебном тиму, а чланови овог тима имају приступ сваком именском простору. Не могу да иду у различите именске просторе, само у своје. Али постоји одређени администраторски налог који има права на цео кластер.
Обећао сам да ћемо прво да добијемо администраторска права за кластер. Потребан нам је посебно припремљен под који ће разбити Кубернетес кластер. Све што треба да урадимо је да га применимо на Кубернетес кластер.
kubectl apply -f pod.yamlОвај под ће стићи једном од господара Кубернетес кластера. И након овога, кластер ће нам радо вратити датотеку под називом админ.цонф. У Цубе-у, ова датотека чува све администраторске сертификате и истовремено конфигурише АПИ кластера. Овако је лако добити администраторски приступ, мислим, за 98% Кубернетес кластера.
Понављам, овај под је направио један програмер у вашем кластеру који има приступ да распореди своје предлоге у један мали простор имена, све је стегнуто од стране РБАЦ-а. Није имао права. Али сертификат је ипак враћен.
А сада о посебно припремљеној махуни. Покрећемо га на било којој слици. Узмимо дебиан:јессие као пример.
Имамо ову ствар:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Шта је толеранција? Мастери у Кубернетес кластеру су обично означени нечим што се зове таинт. А суштина ове „инфекције“ је да каже да се махуне не могу доделити главним чворовима. Али нико се не труди да у било којој махуни назначи да је толерантан на „инфекцију“. Одељак Толерација само каже да ако неки чвор има НоСцхедуле, онда је наш чвор толерантан на такву инфекцију - и нема проблема.
Даље, кажемо да наш под не само да је толерантан, већ жели и да посебно циља на господара. Јер мајстори имају најукусније што нам треба - све сертификате. Стога кажемо нодеСелецтор - и имамо стандардну ознаку на мастерима, која вам омогућава да од свих чворова у кластеру изаберете управо оне чворове који су мастер.
Са ова два дела сигурно ће доћи до мајстора. И биће му дозвољено да тамо живи.
Али само долазак код мајстора није нам довољан. Ово нам неће дати ништа. Дакле, следеће имамо ове две ствари:
hostNetwork: true
hostPID: true Наводимо да ће наш под, који покрећемо, живети у именском простору кернела, у мрежном именском простору и у ПИД именском простору. Када се под покрене на мастеру, моћи ће да види све стварне, живе интерфејсе овог чвора, слуша сав саобраћај и види ПИД свих процеса.
Онда су у питању мале ствари. Узми етцд и читај шта желиш.
Најинтересантнија ствар је ова Кубернетес функција, која је тамо подразумевано присутна.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host А његова суштина је да у поду који покрећемо можемо рећи, чак и без права на овај кластер, да желимо да креирамо волумен типа хостПатх. То значи да узмемо путању од хоста на којем ћемо покренути - и да га узмемо као волумен. И онда га зовемо именом: домаћин. Монтирамо цео овај хостПатх унутар под. У овом примеру, у директоријум /хост.
Поновит ћу то поново. Рекли смо под-у да дође до мастера, да тамо преузме хостНетворк и хостПИД - и монтира цео роот мастер унутар овог модула.
Разумете да у Дебиан-у имамо басх покренут, а овај басх ради под роот-ом. То јест, управо смо примили роот на мастер, без икаквих права на Кубернетес кластер.
Онда је цео задатак да одете у поддиректоријум /хост /етц/кубернетес/пки, ако се не варам, тамо покупите све мастер сертификате кластера и, сходно томе, постанете администратор кластера.
Ако то погледате на овај начин, ово су нека од најопаснијих права у подовима - без обзира на то која права корисник има:
Ако имам права да покренем под у неком именском простору кластера, онда овај под подразумевано има та права. Могу да покренем привилеговане подове, а то су углавном сва права, практично роот на чвору.
Мој омиљени је Роот корисник. А Кубернетес има ову опцију Рун Ас Нон-Роот. Ово је врста заштите од хакера. Да ли знате шта је „молдавски вирус“? Ако сте одједном хакер и дођете у мој Кубернетес кластер, онда вас ми, јадни администратори, питамо: „Молим вас назначите у својим подовима са којима ћете хаковати мој кластер, покренути као нон-роот. У супротном, десиће се да покренете процес у свом под-у под роот-ом и биће вам врло лако да ме хакујете. Молимо вас да се заштитите од себе."
Волумен путање хоста је, по мом мишљењу, најбржи начин да се добије жељени резултат из Кубернетес кластера.
Али шта са свим овим?
Помисао која би требало да падне на памет сваком нормалном администратору који наиђе на Кубернетес је: „Да, рекао сам ти, Кубернетес не ради. Има рупа у њему. А цела Коцка је срање.” У ствари, постоји таква ствар као што је документација, и ако погледате тамо, постоји одељак .
Ово је иамл објекат – можемо га креирати у Кубернетес кластеру – који контролише безбедносне аспекте посебно у опису подова. То јест, у ствари, контролише права за коришћење било које хостНетворк, хостПИД-а, одређених типова волумена који се налазе у подовима при покретању. Уз помоћ Под Сецурити Полици, све ово се може описати.
Најинтересантнија ствар у вези са политиком безбедности Пода је да у Кубернетес кластеру сви инсталатери ПСП-а нису само ни на који начин описани, већ су једноставно онемогућени подразумевано. Под безбедносна политика је омогућена помоћу додатка за пријем.
У реду, хајде да применимо Политику безбедности Пода у кластер, рецимо да имамо неке сервисне модуле у именском простору, којима само администратори имају приступ. Рецимо, у свим осталим случајевима, махуне имају ограничена права. Зато што највероватније програмери не морају да покрећу привилеговане подове у вашем кластеру.
И изгледа да је код нас све у реду. А наш Кубернетес кластер се не може хаковати за два минута.
Постоји проблем. Највероватније, ако имате Кубернетес кластер, онда је надзор инсталиран на вашем кластеру. Чак бих отишао толико далеко да предвидим да ће се, ако ваш кластер има надзор, звати Прометеј.
Оно што ћу вам рећи ће важити и за оператера Прометхеус и за Прометхеус испоручене у свом чистом облику. Питање је да ако не могу тако брзо да убацим администратора у кластер, онда то значи да морам више да тражим. И могу да тражим уз помоћ вашег праћења.
Вероватно су сви читали исте чланке на Хабреу, а надзор се налази у надзорном именском простору. Хелм цхарт се зове отприлике исто за све. Претпостављам да ћете, ако урадите хелм инсталл стабле/прометхеус, завршити са отприлике истим именима. И највероватније нећу морати ни да погађам ДНС име у вашем кластеру. Зато што је стандардно.
Затим имамо одређене програмере у којима можете покренути одређени под. А онда је из ове махуне врло лако урадити нешто овако:
$ curl http://prometheus-kube-state-metrics.monitoring прометхеус-кубе-стате-метрицс је један од Прометхеус извозника који прикупља метрику из самог Кубернетес АПИ-ја. Тамо има пуно података, шта ради у вашем кластеру, шта је то, које проблеме имате са тим.
Као једноставан пример:
кубе_под_цонтаинер_инфо{намеспаце=“кубе-систем”,под=”кубе-аписервер-к8с- 1″,цонтаинер=”кубе-аписервер”,имаге=
„гцр.ио/гоогле-цонтаинерс/кубе-аписервер:в1.14.5“
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Подношењем једноставног захтева за увијање од непривилеговане махуне, можете добити следеће информације. Ако не знате коју верзију Кубернетеса користите, лако ће вам рећи.
А најинтересантније је да поред приступа кубе-стате-метрицс, можете исто тако лако директно приступити самом Прометеју. Одатле можете прикупљати метрику. Можете чак и да направите метрику одатле. Чак и теоретски, можете направити такав упит из кластера у Прометхеусу, који ће га једноставно искључити. И ваш надзор ће потпуно престати да ради из кластера.
И овде се поставља питање да ли било који спољни надзор прати ваше праћење. Управо сам добио прилику да радим у Кубернетес кластеру без икаквих последица по себе. Нећете ни знати да ја тамо радим, јер више нема надзора.
Баш као и са ПСП-ом, чини се да је проблем у томе што све ове фенси технологије - Кубернетес, Прометхеус - једноставно не раде и пуне су рупа. Не баш.
Постоји тако нешто - .
Ако сте нормалан администратор, онда највероватније знате за Нетворк Полици да је ово само још један иамл, којих већ има доста у кластеру. А неке мрежне политике дефинитивно нису потребне. Чак и ако прочитате шта је мрежна политика, да је то иамл заштитни зид Кубернетеса, омогућава вам да ограничите права приступа између именских простора, између подова, онда сте сигурно одлучили да се заштитни зид у иамл формату у Кубернетес-у заснива на следећим апстракцијама ... Не, не. Ово дефинитивно није неопходно.
Чак и ако нисте рекли својим стручњацима за безбедност да користећи свој Кубернетес можете да направите веома лак и једноставан заштитни зид, и то веома детаљан. Ако ово још не знају и не узнемиравају вас: „Па, дај ми, дај ми...“ Онда вам је у сваком случају потребна мрежна политика да блокирате приступ неким сервисним местима која се могу повући из вашег кластера без икаквог овлашћења.
Као у примеру који сам дао, можете извући метрику стања кубе-а из било ког простора имена у Кубернетес кластеру без икаквих права за то. Мрежне политике су затвориле приступ из свих других именских простора надзорном именском простору и то је то: нема приступа, нема проблема. У свим графиконима који постоје, и стандардни Прометхеус и Прометхеус који је у оператеру, једноставно постоји опција у вредностима кормила да једноставно омогућите мрежне политике за њих. Само треба да га укључите и они ће радити.
Овде заиста постоји један проблем. Будући да сте обичан брадати администратор, највероватније сте одлучили да мрежне смернице нису потребне. И након што сте прочитали све врсте чланака о ресурсима као што је Хабр, одлучили сте да је фланел, посебно са режимом хост-гатеваи, најбоља ствар коју можете изабрати.
Шта да радим?
Можете покушати да поново распоредите мрежно решење које имате у свом Кубернетес кластеру, покушајте да га замените нечим функционалнијим. За исти Калико, на пример. Али одмах желим да кажем да је задатак промене мрежног решења у Кубернетес радном кластеру прилично нетривијалан. Решио сам то два пута (оба пута, међутим, теоретски), али смо чак показали како се то ради у Слурмсу. Нашим студентима смо показали како да променимо мрежно решење у Кубернетес кластеру. У принципу, можете покушати да се уверите да нема застоја на производном кластеру. Али вероватно нећете успети.
А проблем се заправо решава врло једноставно. У кластеру постоје сертификати, а ви знате да ће вам сертификати истећи за годину дана. Па и обично нормално решење са сертификатима у кластеру - зашто се бринемо, подићи ћемо нови кластер у близини, пустити да стари пропадне и све поново распоредити. Истина, кад се поквари, мораћемо да седимо један дан, али ево новог грозда.
Када подигнете нови грозд, у исто време убаците Цалицо уместо фланела.
Шта да радите ако се ваши сертификати издају на сто година и не намеравате да прераспоређујете кластер? Постоји таква ствар као што је Кубе-РБАЦ-Проки. Ово је веома кул развој, омогућава вам да се уградите као бочни контејнер у било који под у Кубернетес кластеру. И заправо додаје ауторизацију овом под кроз РБАЦ самог Кубернетеса.
Постоји један проблем. Раније је ово Кубе-РБАЦ-Проки решење било уграђено у Прометхеус оператера. Али онда је отишао. Сада се модерне верзије ослањају на чињеницу да имате мрежну политику и затворите је користећи их. И зато ћемо морати мало да препишемо графикон. У ствари, ако одете у , постоје примери како се ово користи као приколица, а графикони ће морати да се минимално преписују.
Постоји још један мали проблем. Прометеј није једини који дели своје метрике било коме. Све наше компоненте Кубернетес кластера такође могу да врате сопствене метрике.
Али као што сам већ рекао, ако не можете да приступите кластеру и прикупите информације, онда можете барем донети штету.
Тако да ћу брзо показати два начина како се Кубернетес кластер може уништити.
Насмејаћете се када вам ово кажем, ово су два стварна случаја.
Први метод. Ресурса трошење.
Хајде да покренемо још једну специјалну капсулу. Имаће овакав одељак.
resources:
requests:
cpu: 4
memory: 4Gi Као што знате, захтеви су количина ЦПУ-а и меморије која је резервисана на хосту за одређене подове са захтевима. Ако имамо четворојезгарни хост у Кубернетес кластеру, а четири ЦПУ под-а стигну тамо са захтевима, то значи да ниједан под са захтевима више неће моћи да дође на овај хост.
Ако покренем такав под, онда ћу покренути команду:
$ kubectl scale special-pod --replicas=...Тада нико други неће моћи да се примени на Кубернетес кластер. Зато што ће сви чворови остати без захтева. И тако ћу зауставити ваш Кубернетес кластер. Ако ово урадим увече, могу да зауставим распоређивање на доста дуго времена.
Ако поново погледамо Кубернетес документацију, видећемо ову ствар под називом Лимит Ранге. Он поставља ресурсе за објекте кластера. Можете написати Лимит Ранге објекат у иамл-у, применити га на одређене просторе имена - и онда у овом именском простору можете рећи да имате подразумеване, максималне и минималне ресурсе за подове.
Уз помоћ такве ствари можемо ограничити кориснике у одређеним просторима имена производа тимова у могућности да назначе све врсте гадних ствари на њиховим подовима. Али нажалост, чак и ако кажете кориснику да не могу да покрену подове са захтевима за више од једног ЦПУ-а, постоји тако дивна команда за скалирање, или они могу да скалирају преко контролне табле.
И одавде долази метод број два. Покрећемо 11 под. То је једанаест милијарди. То није зато што сам ја смислио такав број, већ зато што сам га сам видео.
Истинита прича. Касно увече намеравао сам да напустим канцеларију. Видим групу програмера како седе у углу и махнито раде нешто са својим лаптопима. Приђем момцима и питам: "Шта ти се десило?"
Нешто раније, око девет увече, један од програмера се спремао да иде кући. И одлучио сам: "Сада ћу смањити своју апликацију на један." Притиснуо сам једну, али је интернет мало успорио. Поново је притиснуо једну, притиснуо је једну и кликнуо Ентер. Пробао сам све што сам могао. Онда је интернет заживео - и све је почело да се смањује на овај број.
Истина, ова прича се није одиграла на Кубернетесу, у то време је то био Номад. Завршило се чињеницом да је након сат времена наших покушаја да зауставимо Номада у упорним покушајима скалирања, Номад је одговорио да неће престати са скалирањем и да неће радити ништа друго. „Уморан сам, идем. И он се склупчао.
Наравно, покушао сам да урадим исто на Кубернетесу. Кубернетес није био задовољан са једанаест милијарди махуна, рекао је: „Не могу. Надмашује унутрашње штитнике за уста." Али 1 махуна би могло.
Као одговор на милијарду, Коцка се није повукла у себе. Заиста је почео да скалира. Што је процес даље ишао, то му је више времена требало да створи нове махуне. Али процес се ипак наставио. Једини проблем је што ако могу неограничено да покрећем подове у свом именском простору, онда чак и без захтева и ограничења могу да покренем толико подова са неким задацима да ће уз помоћ ових задатака чворови почети да се збрајају у меморији, у ЦПУ-у. Када покренем толико подова, информације из њих би требало да иду у складиште, односно итд. А када тамо стигне превише информација, складиште почиње да се враћа сувише споро - и Кубернетес почиње да постаје досадан.
И још један проблем... Као што знате, контролни елементи Кубернетеса нису једна централна ствар, већ неколико компоненти. Конкретно, постоји менаџер контролера, планер и тако даље. Сви ови момци ће истовремено почети да раде непотребан, глуп посао, који ће временом почети да одузима све више времена. Менаџер контролора ће креирати нове подове. Планер ће покушати да пронађе нови чвор за њих. Највероватније ће вам ускоро понестати нових чворова у вашем кластеру. Кубернетес кластер ће почети да ради све спорије и спорије.
Али одлучио сам да идем још даље. Као што знате, у Кубернетесу постоји таква ствар која се зове услуга. Па, подразумевано у вашим кластерима, највероватније, услуга ради користећи ИП табеле.
Ако, на пример, покренете милијарду подова, а затим користите скрипту да бисте натерали Кубернетис да креира нове услуге:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done На свим чворовима кластера, све више и више нових иптаблес правила ће се генерисати приближно истовремено. Штавише, милијарду иптаблес правила ће бити генерисано за сваку услугу.
Проверио сам целу ову ствар на неколико хиљада, до десет. А проблем је што је већ на овом прагу прилично проблематично извршити ссх чвору. Зато што пакети, пролазећи кроз толико ланаца, почињу да се осећају не баш добро.
И ово се такође решава уз помоћ Кубернетеса. Постоји такав објекат квоте ресурса. Поставља број доступних ресурса и објеката за именски простор у кластеру. Можемо креирати иамл објекат у сваком именском простору Кубернетес кластера. Користећи овај објекат, можемо рећи да имамо одређени број захтева и ограничења додељених за овај именски простор, а затим можемо рећи да је у овом именском простору могуће креирати 10 сервиса и 10 подова. А један програмер може бар да се удави увече. Кубернетес ће му рећи: „Не можете скалирати своје махуне до тог износа, јер ресурс премашује квоту.“ То је то, проблем решен. .
У том погледу јавља се једна проблематична тачка. Осећате како постаје тешко направити простор имена у Кубернетес-у. Да бисмо га створили, морамо узети у обзир многе ствари.
Квота ресурса + гранични опсег + РБАЦ
• Креирајте простор имена
• Направите гранични опсег унутра
• Креирајте унутар квоте ресурса
• Креирајте сервисни налог за ЦИ
• Креирајте повезивање улога за ЦИ и кориснике
• Опционо покрените потребне сервисне модуле
Зато бих желео да искористим ову прилику да поделим своја дешавања. Постоји таква ствар која се зове СДК оператер. Ово је начин да Кубернетес кластер напише операторе за њега. Можете писати изјаве користећи Ансибле.
Прво је било написано у Ансибле-у, а онда сам видео да постоји СДК оператор и преписао Ансибле улогу у оператор. Ова изјава вам омогућава да креирате објекат у Кубернетес кластеру који се зове команда. Унутар команде, омогућава вам да опишете окружење за ову команду у иамл-у. А у тимском окружењу, то нам омогућава да опишемо да додељујемо толико ресурса.
Мало .
И у закључку. Шта са свим овим?
Први. Под безбедносна политика је добра. И упркос чињеници да их ниједан од инсталатера Кубернетеса не користи до данас, и даље морате да их користите у својим кластерима.
Мрежна политика није само још једна непотребна функција. То је оно што је заиста потребно у кластеру.
ЛимитРанге/РесоурцеКуота - време је да га користите. Почели смо да користимо ово давно, и дуго сам био сигуран да га сви користе. Испоставило се да је ово реткост.
Поред онога што сам поменуо током извештаја, постоје недокументоване карактеристике које вам омогућавају да нападнете кластер. Објављено недавно .
Неке ствари су тако тужне и болне. На пример, под одређеним условима, кубелети у Кубернетес кластеру могу дати садржај директоријума чаробњака неовлашћеном кориснику.
Постоје упутства како да репродукујете све што сам вам рекао. Постоје датотеке са примерима производње како изгледају РесоурцеКуота и Под Сецурити Полици. И све ово можете додирнути.
Хвала свима.
Извор: ввв.хабр.цом