Павел Селиванов, архитект за решенија на Southbridge и учител Slurm, одржа презентација на DevOpsConf 2019. Овој говор е дел од една од темите на продлабочениот курс за Kubernetes „Slurm Mega“.
се одржува во Москва на 18-20 ноември.
- Москва, 22-24 ноември.
секогаш на располагање.
Под резот има транскрипт од извештајот.
Добро попладне колеги и оние кои сочувствуваат со нив. Денес ќе зборувам за безбедноста.
Гледам дека денес има многу обезбедувачи во салата. Однапред ви се извинувам ако користам термини од светот на безбедноста не баш како што е вообичаено за вас.
Така се случи дека пред околу шест месеци наидов на еден јавен кластер Кубернетес. Јавно значи дека има n-ти број на именски простори; во овие именски простори има корисници изолирани во нивниот именски простор. Сите овие корисници припаѓаат на различни компании. Па, се претпоставуваше дека овој кластер треба да се користи како CDN. Односно, тие ви даваат кластер, ви даваат корисник таму, одите таму во вашиот именски простор, распоредете ги вашите фронтови.
Мојата претходна компанија се обиде да продаде таква услуга. И од мене беше побарано да го пробијам кластерот за да видам дали ова решение е соодветно или не.
Дојдов до овој кластер. Ми беа дадени ограничени права, ограничен именски простор. Момците таму разбраа што е безбедност. Тие читаа за контрола на пристап заснована на улоги (RBAC) во Kubernetes - и ја извртеа за да не можам да стартувам подлоги одделно од распоредувањата. Не се сеќавам на проблемот што се обидував да го решам со лансирање на подлога без распоредување, но навистина сакав да стартувам само подлога. За среќа, решив да видам какви права имам во кластерот, што можам да правам, што не можам и што се заебале таму. Во исто време, ќе ви кажам што неправилно конфигурирале во RBAC.
Се случи за две минути да прими админ во нивниот кластер, да ги погледнам сите соседни именски простори, да ги видам тековните производствени фронтови на компании кои веќе ја купија услугата и ја распоредија. Едвај можев да се спречам да одам нечиј фронт и да ставам некоја пцовка на главната страница.
Ќе ви кажам со примери како го направив ова и како да се заштитите од ова.
Но, прво да се претставам. Јас се викам Павел Селиванов. Јас сум архитект во Саутбриџ. Ги разбирам Kubernetes, DevOps и секакви фенси работи. Инженерите на Саутбриџ и јас го градиме сето ова и се консултирам.
Покрај нашите главни активности, неодамна започнавме и проекти наречени Slurms. Се обидуваме да ја пренесеме нашата способност да работиме со Кубернетис малку до масите, да ги научиме другите луѓе да работат и со K8.
За што ќе зборувам денес? Темата на извештајот е очигледна - за безбедноста на кластерот Кубернетес. Но, сакам веднаш да кажам дека оваа тема е многу голема - и затоа сакам веднаш да разјаснам за што дефинитивно нема да зборувам. Нема да зборувам за пробиени термини кои веќе се употребени сто пати на Интернет. Сите видови на RBAC и сертификати.
Ќе зборувам за тоа што ме боли мене и моите колеги за безбедноста во кластерот Кубернет. Ги гледаме овие проблеми и кај провајдерите кои обезбедуваат кластери на Kubernetes и кај клиентите кои доаѓаат кај нас. Па дури и од клиенти кои доаѓаат кај нас од други консултантски администраторски компании. Односно, размерите на трагедијата се всушност многу големи.
Има буквално три точки за кои ќе зборувам денес:
- Кориснички права наспроти права на под. Корисничките права и правата на pod не се иста работа.
- Собирање информации за кластерот. Ќе покажам дека можете да ги соберете сите информации што ви се потребни од кластер без да имате посебни права во овој кластер.
- DoS напад на кластерот. Ако не можеме да собереме информации, во секој случај ќе можеме да ставиме кластер. Ќе зборувам за DoS напади на елементи за контрола на кластерот.
Друга општа работа што ќе ја спомнам е на што го тестирав сето ова, на што дефинитивно можам да кажам дека сето тоа функционира.
Како основа ја земаме инсталацијата на кластерот Kubernetes користејќи Kubespray. Ако некој не знае, ова е всушност збир на улоги за Ансибл. Го користиме постојано во нашата работа. Доброто е што можете да го тркалате насекаде - можете да го тркалате на парчиња железо или во облак некаде. Еден метод на инсталација работи во принцип за сè.
Во овој кластер ќе имам Kubernetes v1.14.5. Целиот кластер Cube, кој ќе го разгледаме, е поделен на именски простори, секој именски простор припаѓа на посебен тим, а членовите на овој тим имаат пристап до секој именски простор. Тие не можат да одат во различни именски простори, само во нивните. Но, постои одредена административна сметка која има права на целиот кластер.
Ветив дека првото нешто што ќе направиме е да добиеме администраторски права на кластерот. Потребна ни е специјално подготвена мешунка која ќе го скрши кластерот Кубернетес. Сè што треба да направиме е да го примениме во кластерот Kubernetes.
kubectl apply -f pod.yamlОваа мешунка ќе пристигне до еден од господарите на кластерот Кубернетес. И после ова кластерот среќно ќе ни врати датотека наречена admin.conf. Во Cube, оваа датотека ги зачувува сите администраторски сертификати и во исто време го конфигурира API на кластерот. Еве колку е лесно да се добие административен пристап до, мислам, 98% од кластерите на Кубернетес.
Повторувам, овој подлог е направен од еден развивач во вашиот кластер кој има пристап да ги распореди своите предлози во еден мал именски простор, сето тоа е прицврстено од RBAC. Тој немаше никакви права. Но, сепак сертификатот е вратен.
И сега за специјално подготвен мешун. Го работиме на која било слика. Да го земеме debian:jessie како пример.
Ја имаме оваа работа:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Што е толеранција? Мајсторите во кластерот Kubernetes обично се означени со нешто што се нарекува дамка. И суштината на оваа „инфекција“ е што вели дека мешунките не можат да се доделат на мастер јазли. Но, никој не се мачи да покаже во која било мешунка дека е толерантна на „инфекцијата“. Делот Толеранција само вели дека ако некој јазол има 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 го монтираме во подлогата. Во овој пример, во директориумот /домаќин.
Ќе повторам пак. Му рековме на подлогата да дојде до главниот, да ги земе hostNetwork и hostPID таму - и да го монтира целиот корен на master во оваа подлога.
Разбирате дека во Debian имаме баш трчање, а овој баш работи под коренот. Односно, само што добивме root на мајсторот, без да имаме никакви права во кластерот Кубернетес.
Тогаш целата задача е да отидете во поддиректориумот /домаќин /etc/kubernetes/pki, ако не се лажам, подигнете ги сите мастер сертификати на кластерот таму и, соодветно, станете администратор на кластерот.
Ако го погледнете вака, ова се некои од најопасните права во мешунките - без оглед на тоа какви права има корисникот:
Ако ги имам правата да стартувам подлога во некој именски простор на кластерот, тогаш овој подлог стандардно ги има овие права. Можам да стартувам привилегирани подлоги, и тие се генерално сите права, практично root на јазолот.
Мој омилен е Root корисник. И Kubernetes ја има оваа опција Run As Non-Root. Ова е еден вид заштита од хакер. Дали знаете што е „молдавскиот вирус“? Ако одеднаш сте хакер и дојдете во мојот кластер Kubernetes, тогаш ние, кутрите администратори, прашуваме: „Ве молиме наведете во вашите подлоги со кои ќе го хакирате мојот кластер, работи како не-root. Во спротивно, ќе се случи да го извршите процесот во вашиот под под root, и ќе ви биде многу лесно да ме хакирате. Ве молиме заштитете се од себе“.
Волуменот на патеката на домаќинот е, според мое мислење, најбрзиот начин да се добие посакуваниот резултат од кластерот Кубернетес.
Но, што да се прави со сето ова?
Мислата што треба да дојде кај секој нормален администратор што ќе се сретне со Кубернет е: „Да, ти реков, Кубернетс не работи. Во него има дупки. А целата коцка е срање“. Всушност, постои такво нешто како документација, и ако погледнете таму, има дел .
Ова е објект yaml - можеме да го создадеме во кластерот Kubernetes - кој ги контролира безбедносните аспекти конкретно во описот на подлогите. Тоа е, всушност, ги контролира правата за користење на која било мрежа на хост, хостПИД, одредени типови на јачина што се наоѓаат во мешунките при стартување. Со помош на Pod Security Policy, сето ова може да се опише.
Најинтересното нешто во врска со Политиката за безбедност на Pod е тоа што во кластерот Kubernetes, сите инсталатери на PSP не само што не се опишани на кој било начин, тие едноставно се стандардно оневозможени. Политиката за безбедност на Pod е овозможена со помош на приклучокот за прием.
Добро, ајде да ја распоредиме Политиката за безбедност на Pod во кластерот, да речеме дека имаме некои места за услуги во именскиот простор, до кои пристап имаат само администраторите. Да речеме, во сите други случаи, мешунките имаат ограничени права. Затоа што, најверојатно, програмерите не треба да извршуваат привилегирани подлоги во вашиот кластер.
И се чини дека сè е во ред со нас. И нашиот Kubernetes кластер не може да се хакира за две минути.
Има проблем. Најверојатно, ако имате кластер Kubernetes, тогаш мониторингот е инсталиран на вашиот кластер. Дури би отишол дотаму што предвидувам дека ако вашиот кластер има мониторинг, тој ќе се вика Прометеј.
Она што ќе ви го кажам ќе важи и за операторот Prometheus и за 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-apiserver: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, исто толку лесно можете директно да пристапите и до самиот Прометеј. Од таму можете да собирате метрика. Од таму можете дури и да изградите метрика. Дури и теоретски, можете да изградите такво барање од кластер во Прометеј, што едноставно ќе го исклучи. И вашиот мониторинг целосно ќе престане да работи од кластерот.
И тука се поставува прашањето дали некој надворешен мониторинг го следи вашето следење. Само што добив можност да оперирам во кластер на Кубернетес без никакви последици за себе. Нема ни да знаете дека оперирам таму, бидејќи веќе нема мониторинг.
Исто како и со PSP, се чини дека проблемот е во тоа што сите овие фенси технологии - Kubernetes, Prometheus - тие едноставно не работат и се полни со дупки. Не навистина.
Има такво нешто - .
Ако сте нормален администратор, тогаш најверојатно знаете за мрежната политика дека ова е само уште еден јамл, од кој веќе има многу од нив во кластерот. И некои мрежни политики дефинитивно не се потребни. И дури и ако прочитате што е мрежна политика, дека тоа е заштитниот ѕид yaml на Kubernetes, ви овозможува да ги ограничите правата за пристап помеѓу именските простори, помеѓу местата, тогаш сигурно сте решиле дека заштитниот ѕид во формат yaml во Kubernetes се базира на следните апстракции ... Не, не. Ова дефинитивно не е потребно.
Дури и ако не сте им кажале на вашите специјалисти за безбедност дека користејќи го вашиот Kubernetes можете да изградите многу лесен и едноставен заштитен ѕид, а притоа и многу грануларен. Ако сè уште не го знаат ова и не ви пречат: „Па, дај ми, дај ми...“ Тогаш, во секој случај, потребна ви е мрежна политика за да го блокирате пристапот до некои сервисни места што може да се извлечат од вашиот кластер без никакво овластување.
Како и во примерот што го наведов, можете да повлечете метрика на состојбата на kube од кој било именски простор во кластерот Kubernetes без да имате никакви права за тоа. Мрежните политики имаат затворен пристап од сите други именски простори до именскиот простор за следење и тоа е сè: нема пристап, нема проблеми. Во сите графикони што постојат, и стандардниот Prometheus и Prometheus што е во операторот, едноставно постои опција во вредностите на кормилото едноставно да се овозможат мрежни политики за нив. Треба само да го вклучите и тие ќе работат.
Тука навистина има еден проблем. Како нормален администратор со брада, најверојатно сте решиле дека не се потребни мрежни политики. И откако прочитавте секакви написи за ресурси како Habr, решивте дека фланелот, особено со режимот на домаќин-порта, е најдоброто нешто што можете да го изберете.
Што да правам?
Може да се обидете да го прераспоредите мрежното решение што го имате во вашиот кластер Kubernetes, обидете се да го замените со нешто пофункционално. За истото Калико, на пример. Но, сакам веднаш да кажам дека задачата за промена на мрежното решение во работниот кластер Kubernetes е сосема нетривијална. Го решив двапати (двата пати, сепак, теоретски), но дури и покажавме како се прави тоа на Слурмс. За нашите студенти, покажавме како да го смените мрежното решение во кластерот Кубернетес. Во принцип, можете да се обидете да се осигурате дека нема застој на производниот кластер. Но, веројатно нема да успеете.
А проблемот всушност е решен многу едноставно. Има сертификати во кластерот и знаете дека вашите сертификати ќе истечат за една година. Па, и обично нормално решение со сертификати во кластерот - зошто се грижиме, ќе подигнеме нов кластер во близина, ќе оставиме стариот да се расипе и ќе прераспоредиме сè. Точно, кога ќе се расипе, ќе треба да седиме еден ден, но еве нов кластер.
Кога ќе подигнете нов кластер, во исто време ставете Calico наместо фланелен.
Што да направите ако вашите сертификати се издаваат сто години и нема да го прераспределите кластерот? Постои такво нешто како Kube-RBAC-Proxy. Ова е многу кул развој, што ви овозможува да се вградите како контејнер за странична кола во која било подлога во кластерот Кубернетес. И, всушност, додава овластување на оваа подлога преку самиот RBAC на Kubernetes.
Има еден проблем. Претходно, ова решение Kube-RBAC-Proxy беше вградено во Prometheus на операторот. Но, тогаш го немаше. Сега модерните верзии се потпираат на фактот дека имате мрежна политика и ја затворате користејќи ги. И затоа ќе треба малку да ја преработиме табелата. Всушност, ако одите на , има примери за тоа како да се користи ова како странични кола, а графиконите ќе треба да се препишуваат минимално.
Има уште еден мал проблем. Прометеј не е единствениот кој ги раздава своите метрики на секого. Сите наши компоненти на кластерот Kubernetes исто така можат да вратат свои метрики.
Но, како што веќе реков, ако не можете да пристапите до кластерот и да собирате информации, тогаш можете барем да направите некоја штета.
Така, брзо ќе покажам два начини како може да се уништи кластерот Кубернетес.
Ќе се насмеете кога ќе ви го кажам ова, ова се два реални случаи.
Метод еден. Исцрпување на ресурсите.
Ајде да лансираме уште една специјална подлога. Ќе има ваков дел.
resources:
requests:
cpu: 4
memory: 4Gi Како што знаете, барањата е количината на процесорот и меморијата што се резервирани на домаќинот за одредени подлоги со барања. Ако имаме четири-јадрен хост во кластерот Kubernetes и четири процесорски подлоги пристигнуваат таму со барања, тоа значи дека нема да може да дојде до овој хост повеќе места со барања.
Ако стартувам таков подлога, тогаш ќе ја извршам командата:
$ kubectl scale special-pod --replicas=...Тогаш никој друг нема да може да се распореди во кластерот Кубернетес. Бидејќи сите јазли ќе останат без барања. И така ќе го прекинам вашиот кластер Кубернетес. Ако го направам ова навечер, можам да ги прекинам распоредувањата доста долго.
Ако повторно ја погледнеме документацијата на Кубернетес, ќе ја видиме оваа работа наречена Ограничен опсег. Ги поставува ресурсите за објектите на кластерот. Можете да напишете објект Limit Range во yaml, да го примените на одредени именски простори - и потоа во овој именски простор можете да кажете дека имате стандардни, максимални и минимални ресурси за pods.
Со помош на такво нешто, можеме да ги ограничиме корисниците во одредени места со имиња на производи на тимови во способноста да укажуваат на секакви непријатни работи на нивните парчиња. Но, за жал, дури и ако му кажете на корисникот дека не може да стартува подлоги со барања за повеќе од еден процесор, постои таква прекрасна команда за скала или може да направи скала преку контролната табла.
И оттука доаѓа методот број два. Лансираме 11 парчиња. Тоа се единаесет милијарди. Ова не е затоа што дојдов до таков број, туку затоа што сам го видов.
Вистинска приказна. Доцна вечерта требаше да ја напуштам канцеларијата. Гледам група програмери како седат во аголот, избезумено прават нешто со своите лаптопи. Одам кај момците и ги прашувам: „Што се случи со тебе?
Малку порано, околу девет навечер, еден од програмерите се подготвуваше да си оди дома. И решив: „Сега ќе ја намалам мојата апликација на една“. Притиснав еден, но интернетот малку забави. Повторно го притисна едното, го притисна едното и кликна Enter. Ѕирнав по се што можев. Потоа оживеа Интернетот - и сè почна да се намалува на оваа бројка.
Точно, оваа приказна не се случи на Кубернетес; во тоа време тоа беше Номад. Се заврши со фактот дека по еден час од нашите обиди да го спречиме Номад од упорните обиди за скалирање, Номад одговори дека нема да престане да се зголемува и нема да направи ништо друго. „Уморен сум, си одам. И се свитка.
Секако, се обидов да го направам истото на Кубернетес. Кубернетес не беше задоволен со единаесет милијарди мешунки, тој рече: „Не можам. Ги надминува внатрешните штитници на устата“. Но, 1 мешунки би можеле.
Како одговор на една милијарда, коцката не се повлече во себе. Навистина почна да се скалира. Колку подалеку одеше процесот, толку повеќе време му требаше да создаде нови мешунки. Но, сепак процесот продолжи. Единствениот проблем е што ако можам неограничено да стартувам pods во мојот именски простор, тогаш дури и без барања и ограничувања можам да стартувам толку многу pods со некои задачи што со помош на овие задачи јазлите ќе почнат да се собираат во меморијата, во процесорот. Кога ќе стартувам толку многу подлоги, информациите од нив треба да одат во складиште, односно итн. И кога ќе пристигнат премногу информации таму, складирањето почнува да се враќа премногу бавно - а Kubernetes почнува да станува досаден.
И уште еден проблем... Како што знаете, контролните елементи на Kubernetes не се една централна работа, туку неколку компоненти. Конкретно, постои контролер менаџер, распоредувач и така натаму. Сите овие момци ќе почнат да вршат непотребна, глупава работа во исто време, која со текот на времето ќе почне да одзема се повеќе и повеќе време. Менаџерот на контролорот ќе создаде нови подлоги. Распоредувачот ќе се обиде да најде нов јазол за нив. Најверојатно наскоро ќе останете без нови јазли во вашиот кластер. Кластерот Kubernetes ќе почне да работи побавно и побавно.
Но, решив да одам уште подалеку. Како што знаете, во Кубернетес постои такво нешто што се нарекува услуга. Па, стандардно во вашите кластери, најверојатно, услугата работи со користење на IP табели.
Ако извршите една милијарда подлога, на пример, и потоа користите скрипта за да го принудите Кубернетис да создаде нови услуги:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done На сите јазли од кластерот, се повеќе и повеќе нови правила за iptables ќе се генерираат приближно истовремено. Покрај тоа, една милијарда правила за iptables ќе бидат генерирани за секоја услуга.
Целата оваа работа ја проверив на неколку илјади, до десет. И проблемот е што веќе на овој праг е доста проблематично да се направи ssh на јазолот. Бидејќи пакетите, поминувајќи низ толку многу синџири, почнуваат да се чувствуваат не многу добро.
И ова, исто така, сето тоа е решено со помош на Кубернетес. Постои таков објект за квота на ресурси. Го поставува бројот на достапни ресурси и објекти за именскиот простор во кластерот. Можеме да создадеме објект yaml во секој именски простор на кластерот Kubernetes. Користејќи го овој објект, можеме да кажеме дека имаме одреден број барања и ограничувања доделени за овој именски простор, а потоа можеме да кажеме дека во овој именски простор е можно да се создадат 10 услуги и 10 подови. И еден програмер може барем да се задави навечер. Кубернетес ќе му каже: „Не можете да ги зголемите вашите мешунки до тој износ, бидејќи ресурсот ја надминува квотата“. Тоа е тоа, проблемот е решен. .
Во овој поглед се јавува една проблематична точка. Чувствувате колку е тешко да се создаде именски простор во Kubernetes. За да го создадеме, треба да земеме предвид многу работи.
Квота на ресурси + Ограничен опсег + RBAC
• Направете именски простор
• Создадете граничен опсег внатре
• Креирај внатре квота за ресурси
• Создадете сервисна сметка за CI
• Создадете улоги за CI и корисниците
• Изборно стартувајте ги потребните подлоги за услуги
Затоа, би сакал да ја искористам оваа прилика да го споделам мојот развој. Постои такво нешто што се нарекува оператор SDK. Ова е начин на Kubernetes кластер да пишува оператори за него. Можете да пишувате изјави користејќи Ansible.
Отпрвин беше напишано во Ansible, а потоа видов дека има SDK оператор и ја препишав улогата на Ansible во оператор. Оваа изјава ви овозможува да креирате објект во кластерот Kubernetes наречен команда. Внатре во командата, ви овозможува да ја опишете околината за оваа команда во yaml. И во рамките на тимското опкружување, ни овозможува да опишеме дека доделуваме толку многу ресурси.
Малку .
И како заклучок. Што да се прави со сето ова?
Прво. Политиката за безбедност на Pod е добра. И покрај фактот што ниту еден од инсталаторите на Кубернетс не ги користи до ден-денес, сепак треба да ги користите во вашите кластери.
Мрежна политика не е само уште една непотребна карактеристика. Ова е она што навистина е потребно во еден кластер.
LimitRange/ResourceQuota - време е да го искористите. Почнавме да го користиме ова одамна и долго време бев сигурен дека сите го користат. Се испостави дека ова е ретко.
Покрај она што го спомнав за време на извештајот, има недокументирани функции кои ви дозволуваат да го нападнете кластерот. Објавен неодамна .
Некои работи се толку тажни и повредливи. На пример, под одредени услови, cubelets во кластерот Kubernetes може да ја дадат содржината на директориумот warlocks на неовластен корисник.
Има инструкции како да го репродуцирате сето она што ви кажав. Постојат датотеки со примери за производство за тоа како изгледаат ResourceQuota и Pod Security Policy. И можете да го допрете сето ова.
Ви благодарам на сите.
Извор: www.habr.com