Pavel Selivanov, Southbridge'i lahenduste arhitekt ja Slurmi õpetaja, esines ettekandega DevOpsConf 2019. See jutt on osa Kubernetese süvakursuse “Slurm Mega” ühest teemast.
toimub Moskvas 18.-20.novembril.
— Moskva, 22.–24. november.
alati saadaval.
Lõike all on aruande ärakiri.
Tere pärastlõunast, kolleegid ja need, kes neile kaasa tunnevad. Täna räägin ohutusest.
Vaatan, et täna on saalis palju turvamehi. Vabandan teie ees juba ette, kui kasutan turvamaailma termineid mitte täpselt nii, nagu teile kombeks on.
Juhtus nii, et umbes kuus kuud tagasi sattusin ühe avaliku Kubernetese klastri peale. Avalik tähendab, et seal on n-s arv nimeruume; nendes nimeruumides on kasutajad oma nimeruumis isoleeritud. Kõik need kasutajad kuuluvad erinevatele ettevõtetele. Noh, eeldati, et seda klastrit tuleks kasutada CDN-ina. See tähendab, et nad annavad teile klastri, nad annavad teile sinna kasutaja, te lähete sinna oma nimeruumi, juurutage oma rinded.
Minu eelmine ettevõte üritas sellist teenust müüa. Ja mul paluti klastrit torkida, et kas see lahendus sobib või mitte.
Jõudsin sellesse klastrisse. Mulle anti piiratud õigused, piiratud nimeruum. Sealsed poisid said aru, mis on ohutus. Nad lugesid Kubernetes'i rollipõhise juurdepääsu juhtimise (RBAC) kohta – ja väänasid seda nii, et ma ei saaks kaubikuid juurutustest eraldi käivitada. Ma ei mäleta probleemi, mida üritasin lahendada ilma juurutamiseta podi käivitamisega, kuid ma tõesti tahtsin käivitada ainult podi. Hea õnne nimel otsustasin vaadata, millised õigused mul klastris on, mida ma saan teha, mida ma ei saa teha ja mida nad on seal seganud. Samal ajal ütlen teile, mida nad on RBAC-is valesti seadistanud.
Juhtus nii, et kahe minuti pärast sain nende klastrisse administraatori, vaatasin üle kõik naabernimeruumid, nägin seal juba teenuse ostnud ja kasutusele võtnud ettevõtete tootmisrinde. Suutsin vaevu peatada end kellegi ette astumast ja avalehele sõimusõna panemast.
Ma räägin teile näidetega, kuidas ma seda tegin ja kuidas end selle eest kaitsta.
Aga kõigepealt lubage mul ennast tutvustada. Minu nimi on Pavel Selivanov. Olen Southbridge'i arhitekt. Ma saan aru Kubernetesest, DevOpsist ja igasugustest uhketest asjadest. Southbridge'i insenerid ja mina ehitame seda kõike ja ma konsulteerin.
Lisaks põhitegevusele oleme hiljuti käivitanud projekte nimega Slurms. Üritame oma oskust Kubernetesega töötada veidi massidesse, õpetada ka teisi inimesi K8-dega töötama.
Millest ma täna räägin? Raporti teema on ilmne – Kubernetese klastri turvalisusest. Kuid ma tahan kohe öelda, et see teema on väga mahukas - ja seetõttu tahan kohe selgitada, millest ma kindlasti ei räägi. Ma ei hakka rääkima hakitud terminitest, mida on Internetis juba sada korda kasutatud. Igasugused RBAC ja sertifikaadid.
Räägin sellest, mis mulle ja mu kolleegidele Kubernetese klastri turvalisuse osas valutab. Näeme neid probleeme nii Kubernetese klastreid pakkuvate pakkujate kui ka meie juurde pöörduvate klientide seas. Ja isegi klientidelt, kes tulevad meie juurde teistest nõustamisadministraatorifirmadest. See tähendab, et tragöödia ulatus on tegelikult väga suur.
Täna räägin sõna otseses mõttes kolmest punktist:
- Kasutajaõigused vs. Kasutajaõigused ja podiõigused ei ole sama asi.
- Teabe kogumine klastri kohta. Näitan, et saate koguda klastrist kogu vajaliku teabe, ilma et teil oleks selles klastris eriõigusi.
- DoS rünnak klastrile. Kui me ei saa teavet koguda, saame igal juhul klastri panna. Ma räägin DoS-i rünnakutest klastri juhtimiselementide vastu.
Veel üks üldine asi, mida ma mainin, on see, mille peal ma seda kõike testisin, mille põhjal võin kindlalt öelda, et see kõik töötab.
Võtame aluseks Kubernetese klastri paigaldamise Kubespray abil. Kui keegi ei tea, siis tegelikult on see Ansible'i rollide komplekt. Kasutame seda pidevalt oma töös. Hea on see, et saad seda kõikjale veeretada – võid veeretada rauatükkidele või kuskile pilve sisse. Üks paigaldusmeetod töötab põhimõtteliselt kõige jaoks.
Selles klastris on mul Kubernetes v1.14.5. Kogu Cube'i klaster, mida me käsitleme, on jagatud nimeruumideks, iga nimeruum kuulub eraldi meeskonnale ja selle meeskonna liikmetel on juurdepääs igale nimeruumile. Nad ei saa minna erinevatesse nimeruumidesse, vaid ainult enda nimeruumidesse. Kuid on teatud administraatori konto, millel on õigused kogu klastrile.
Lubasin, et esimese asjana hankime klastri administraatoriõigused. Vajame spetsiaalselt ettevalmistatud kauna, mis purustab Kubernetese klastri. Kõik, mida peame tegema, on selle rakendamine Kubernetese klastris.
kubectl apply -f pod.yamlSee kaun jõuab ühele Kubernetese klastri meistrile. Ja pärast seda tagastab klaster meile hea meelega faili nimega admin.conf. Cube'is salvestab see fail kõik administraatori sertifikaadid ja konfigureerib samal ajal klastri API. Nii lihtne on saada administraatori juurdepääs minu arvates 98% Kubernetese klastritele.
Kordan, selle tasku koostas üks teie klastri arendaja, kellel on juurdepääs oma ettepanekute juurutamiseks ühte väikesesse nimeruumi. Kõik see on kinnitatud RBAC-iga. Tal polnud õigusi. Kuid sellegipoolest saadi tunnistus tagasi.
Ja nüüd spetsiaalselt valmistatud kaunast. Käitame seda mis tahes pildil. Võtame näiteks debian:jessie.
Meil on selline asi:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Mis on tolerantsus? Kubernetese klastris olevad meistrid on tavaliselt tähistatud millegi nimetusega must. Ja selle "nakkuse" olemus seisneb selles, et kaunasid ei saa põhisõlmedele määrata. Kuid keegi ei vaevu üheski kaunas märkima, et see on “nakkuse” suhtes tolerantne. Jaotises Toleration öeldakse lihtsalt, et kui mõnel sõlmel on NoSchedule, siis meie sõlm on sellise infektsiooni suhtes tolerantne – ja probleeme pole.
Lisaks ütleme, et meie all ei ole mitte ainult tolerantne, vaid soovib ka konkreetselt meistrit sihtida. Sest meistritel on kõige maitsvam, mida vajame – kõik sertifikaadid. Seetõttu ütleme nodeSelector - ja meil on ülemseadmetel standardne silt, mis võimaldab teil valida kõigi klastri sõlmede hulgast täpselt need sõlmed, mis on ülemad.
Nende kahe lõiguga tuleb ta kindlasti meistri juurde. Ja tal lubatakse seal elada.
Aga ainult meistri juurde tulemisest meile ei piisa. See ei anna meile midagi. Järgmisena on meil kaks asja:
hostNetwork: true
hostPID: true Täpsustame, et meie pod, mille käivitame, asub kerneli nimeruumis, võrgu nimeruumis ja PID-nimeruumis. Kui pod on põhiseadmes käivitatud, näeb see kõiki selle sõlme tegelikke reaalajas liideseid, kuulab kogu liiklust ja näeb kõigi protsesside PID-sid.
Siis on asi pisiasjades. Võta jne ja loe, mida tahad.
Kõige huvitavam on see Kubernetese funktsioon, mis seal vaikimisi olemas on.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Ja selle olemus seisneb selles, et saame podis öelda, et käivitame isegi ilma selle klastri õigusteta, et tahame luua hostPath tüüpi köite. See tähendab, et võtame selle hosti tee, millel käivitame, ja võtame selle mahuna. Ja siis kutsume seda nimeks: host. Paigaldame kogu selle hostPathi podi sisse. Selles näites kataloogi /host.
Ma kordan seda uuesti. Käskisime podil tulla masteri juurde, hankida seal hostNetwork ja hostPID – ning ühendada kogu ülemseadme juur sellesse podi.
Saate aru, et Debianis töötab bash ja see bash töötab root all. See tähendab, et saime just ülemseadme juure, ilma et meil oleks Kubernetese klastris õigusi.
Seejärel on kogu ülesanne minna alamkataloogi /host /etc/kubernetes/pki, kui ma ei eksi, korja sealt üles kõik klastri põhisertifikaadid ja asuge vastavalt klastri administraatoriks.
Kui vaatate seda nii, on need ühed kõige ohtlikumad õigused kaustades – olenemata sellest, millised õigused kasutajal on:
Kui mul on õigused podi käitada mõnes klastri nimeruumis, on sellel podil vaikimisi need õigused. Saan käitada privilegeeritud kaustasid ja need on üldiselt kõik õigused, praktiliselt juur sõlmes.
Minu lemmik on Root kasutaja. Ja Kubernetesil on see suvand Run As Non-Root. See on teatud tüüpi kaitse häkkerite eest. Kas teate, mis on "Moldavia viirus"? Kui olete järsku häkker ja jõuate minu Kubernetese klastrisse, siis meie, vaesed administraatorid, küsime: "Palun märkige oma kaunadesse, millega te minu klastrit häkkite, käivitage mitte-root. Vastasel juhul juhtub, et käivitate protsessi oma podis root all ja teil on väga lihtne mind häkkida. Palun kaitske end enda eest."
Hostitee maht on minu arvates kiireim viis Kubernetese klastrist soovitud tulemuse saamiseks.
Aga mida selle kõigega peale hakata?
Mõte, mis peaks igal tavalisel administraatoril, kes Kubernetesega kokku puutub, peaks tulema: "Jah, ma ütlesin teile, et Kubernetes ei tööta. Selles on augud. Ja kogu Kuubik on jama." Tegelikult on olemas selline asi nagu dokumentatsioon ja kui seal vaadata, siis seal on jagu .
See on yaml-objekt – saame selle luua Kubernetese klastris –, mis juhib turvaaspekte konkreetselt kaunade kirjelduses. See tähendab, et tegelikult juhib see õigusi kasutada mis tahes hostivõrku, hostPID-d ja teatud köitetüüpe, mis on käivitamisel kaunades. Podi turvapoliitika abil saab seda kõike kirjeldada.
Podi turbepoliitika kõige huvitavam asi on see, et Kubernetese klastris pole kõiki PSP installijaid lihtsalt mitte mingil viisil kirjeldatud, vaid need on vaikimisi lihtsalt keelatud. Podi turvapoliitika on lubatud sissepääsuplugina abil.
Olgu, juurutame klastris Podi turbepoliitika, oletame, et meil on nimeruumis mõned teenusepoodid, millele on juurdepääs ainult administraatoritel. Oletame, et kõigil muudel juhtudel on kaunadel piiratud õigused. Kuna tõenäoliselt ei pea arendajad teie klastris privilegeeritud kaunasid käivitama.
Ja tundub, et meiega on kõik korras. Ja meie Kubernetese klastrit ei saa kahe minutiga häkkida.
Tekkis probleem. Tõenäoliselt, kui teil on Kubernetese klaster, installitakse teie klastrisse seire. Ma läheksin isegi nii kaugele, et ennustaksin, et kui teie klastris on monitooring, nimetatakse seda Prometheuks.
See, mida ma teile ütlen, kehtib nii Prometheuse operaatori kui ka puhtal kujul tarnitud Prometheuse kohta. Küsimus on selles, et kui ma ei saa nii kiiresti administraatorit klastrisse, siis see tähendab, et pean rohkem otsima. Ja ma saan teie jälgimise abil otsida.
Tõenäoliselt loevad kõik Habré kohta samu artikleid ja monitooring asub monitooringu nimeruumis. Helmi diagrammi nimetatakse kõigi jaoks ligikaudu samaks. Ma arvan, et kui installite stable/prometheuse, saate umbes samade nimedega. Ja tõenäoliselt ei pea ma isegi teie klastri DNS-nime ära arvama. Sest see on standardne.
Järgmisena on meil teatud dev ns, milles saate käivitada teatud pod. Ja siis on sellest kaustast väga lihtne teha midagi sellist:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics on üks Prometheuse eksportijatest, kes kogub mõõdikuid Kubernetes API-lt endalt. Seal on palju andmeid, mis teie klastris töötab, mis see on, millised probleemid teil sellega on.
Lihtsa näitena:
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
Kui esitate privilegeerimata seadmest lihtsa koolutamistaotluse, saate järgmise teabe. Kui te ei tea, millist Kubernetese versiooni kasutate, ütleb see teile hõlpsalt.
Ja mis kõige huvitavam on see, et lisaks kube-state-metricsile ligipääsule pääsete sama lihtsalt otse Prometheusele endale. Sealt saab mõõdikuid koguda. Sealt saate isegi mõõdikuid koostada. Isegi teoreetiliselt saate sellise päringu koostada Prometheuse klastrist, mis selle lihtsalt välja lülitab. Ja teie jälgimine lakkab klastrist üldse töötamast.
Ja siin tekib küsimus, kas teie seiret jälgib mõni väline monitooring. Sain just võimaluse tegutseda Kubernetese klastris ilma enda jaoks tagajärgedeta. Te isegi ei tea, et ma seal tegutsen, sest seal pole enam järelevalvet.
Täpselt nagu PSP puhul on probleem selles, et kõik need uhked tehnoloogiad – Kubernetes, Prometheus – lihtsalt ei tööta ja on auke täis. Mitte päris.
On selline asi - .
Kui olete tavaline administraator, siis tõenäoliselt teate võrgupoliitika kohta, et see on lihtsalt järjekordne yaml, mida klastris on juba palju. Ja mõnda võrgupoliitikat pole kindlasti vaja. Ja isegi kui loete, mis on võrgupoliitika, et see on Kubernetese yamli tulemüür, mis võimaldab teil piirata juurdepääsuõigusi nimeruumide vahel, kaustade vahel, siis otsustasite kindlasti, et Kubernetese yaml-vormingus tulemüür põhineb järgmistel abstraktsioonidel. ... Ei, ei. See pole kindlasti vajalik.
Isegi kui te ei rääkinud oma turvaspetsialistidele, et Kubernetese abil saate luua väga lihtsa ja lihtsa tulemüüri ning seejuures väga üksikasjaliku tulemüüri. Kui nad seda veel ei tea ja teid ei häiri: "Noh, anna mulle, anna mulle..." Siis on teil igal juhul vaja võrgupoliitikat, et blokeerida juurdepääs mõnele teeninduskohale, mida saab teie klastrist tõmmata. ilma igasuguse loata.
Nagu minu toodud näites, saate Kubernetese klastri mis tahes nimeruumist üles tõmmata kube olekumõõdikud, ilma et teil oleks selleks õigusi. Võrgupoliitikad on sulgenud juurdepääsu kõigist teistest nimeruumidest jälgitavale nimeruumile ja see on kõik: pole juurdepääsu, pole probleeme. Kõigis olemasolevates diagrammides, nii tavalises Prometheuses kui ka operaatoris olevas Prometheuses, on tüüri väärtustes lihtsalt võimalus nende jaoks võrgupoliitikad lihtsalt lubada. Peate selle lihtsalt sisse lülitama ja nad töötavad.
Siin on tõesti üks probleem. Tavalise habemega administraatorina otsustasite tõenäoliselt, et võrgupoliitikat pole vaja. Ja olles lugenud kõikvõimalikke artikleid selliste ressursside kohta nagu Habr, otsustasite, et flanell, eriti host-lüüsi režiimis, on parim, mida saate valida.
Mida teha?
Võite proovida Kubernetese klastris olevat võrgulahendust ümber paigutada, proovida asendada see millegi funktsionaalsemaga. Sellele samale Calicole näiteks. Kuid ma tahan kohe öelda, et Kubernetese tööklastri võrgulahenduse muutmise ülesanne on üsna ebaoluline. Lahendasin seda kaks korda (mõlemal korral siiski teoreetiliselt), aga Slurmsis näitasime isegi, kuidas seda teha. Näitasime õpilastele, kuidas Kubernetese klastris võrgulahendust muuta. Põhimõtteliselt võite proovida veenduda, et tootmisklastris pole seisakuid. Aga see sul tõenäoliselt ei õnnestu.
Ja probleem lahendatakse tegelikult väga lihtsalt. Klastris on sertifikaadid ja teate, et teie sertifikaadid aeguvad aasta pärast. Noh, ja tavaliselt tavaline lahendus klastris olevate sertifikaatidega - miks me muretseme, tõstame lähedale uue klastri, laseme vanal mädaneda ja paigutame kõik ümber. Tõsi, kui see mädaneb, peame päeva istuma, kuid siin on uus klaster.
Kui tõstate uue klastri, sisestage samal ajal flanelli asemel Calico.
Mida teha, kui teie sertifikaate väljastatakse sajaks aastaks ja te ei kavatse klastrit ümber paigutada? On olemas selline asi nagu Kube-RBAC-Puhverserver. See on väga lahe arendus, see võimaldab teil manustada end külgkorvi konteinerina igasse Kubernetese klastrisse. Ja tegelikult lisab see sellele podile volitused Kubernetese enda RBAC-i kaudu.
On üks probleem. Varem oli see Kube-RBAC-puhverserveri lahendus sisse ehitatud operaatori Prometheusesse. Aga siis oli ta läinud. Nüüd tuginevad kaasaegsed versioonid sellele, et teil on võrgupoliitika ja sulgege see nende abil. Ja seetõttu peame diagrammi veidi ümber kirjutama. Tegelikult, kui lähete , on näiteid selle kohta, kuidas seda külgkorvidena kasutada, ja graafikuid tuleb minimaalselt ümber kirjutada.
Üks väike probleem on veel. Prometheus pole ainus, kes jagab oma mõõdikuid kõigile. Kõik meie Kubernetese klastri komponendid saavad ka oma mõõdikuid tagastada.
Kuid nagu ma juba ütlesin, kui te ei pääse klastrile juurde ega kogu teavet, võite vähemalt kahju teha.
Nii et näitan kiiresti kahte võimalust, kuidas Kubernetese klastrit rikkuda.
Te naerate, kui ma teile seda ütlen, need on kaks reaalset juhtumit.
Meetod üks. Ressursi ammendumine.
Käivitame veel ühe erilise podi. Sellel on selline jaotis.
resources:
requests:
cpu: 4
memory: 4Gi Nagu teate, on päringud protsessori ja mälu hulk, mis on hostis reserveeritud konkreetsete päringutega kaustade jaoks. Kui meil on Kubernetese klastris neljatuumaline host ja sinna saabuvad päringutega neli CPU-kassetti, tähendab see, et sellesse hosti ei saa enam päringutega taskuid tulla.
Kui käivitan sellise podi, käivitan käsu:
$ kubectl scale special-pod --replicas=...Siis ei saa keegi teine Kubernetese klastris kasutusele võtta. Kuna kõigi sõlmede päringud saavad otsa. Ja seega peatan teie Kubernetese klastri. Kui teen seda õhtul, võin juurutused üsna pikaks ajaks peatada.
Kui vaatame uuesti Kubernetese dokumentatsiooni, näeme seda asja nimega Limit Range. See määrab klastriobjektide jaoks ressursid. Sa võid kirjutada yamlis Limit Range objekti, rakendada seda teatud nimeruumidele – ja siis selles nimeruumis saad öelda, et sul on podide jaoks vaikimisi, maksimaalne ja minimaalne ressurss.
Sellise asja abil saame piirata kasutajate võimalust tiimide konkreetsetes tootenimeruumides näidata oma kaustadel kõikvõimalikke ebameeldivaid asju. Kuid kahjuks, isegi kui ütlete kasutajale, et ta ei saa käivitada kaustasid, millel on taotlus rohkem kui ühe protsessori jaoks, on olemas selline suurepärane skaleerimiskäsk või nad saavad skaleerida armatuurlaua kaudu.
Ja siit tuleb meetod number kaks. Toome turule 11 111 111 111 111 kauna. See on üksteist miljardit. Seda mitte sellepärast, et ma sellise numbri välja mõtlesin, vaid sellepärast, et ma ise nägin seda.
Päris lugu. Hilisõhtul hakkasin kontorist lahkuma. Näen nurgas istuvat gruppi arendajaid ja teevad meeletult midagi oma sülearvutitega. Lähen poiste juurde ja küsin: "Mis teiega juhtus?"
Veidi varem, kella üheksa paiku õhtul valmistus üks arendaja kojuminekuks. Ja ma otsustasin: "Ma vähendan nüüd oma taotlust ühele." Vajutasin ühte, aga internet aeglustus veidi. Ta vajutas uuesti ühte, ta vajutas ühte ja klõpsas sisestusklahvi. Torkasin kõike, mida suutsin. Siis sai Internet ellu – ja kõik hakkas selle numbrini taanduma.
Tõsi, see lugu ei toimunud Kubernetes, tol ajal oli see Nomad. See lõppes sellega, et pärast tund aega kestnud meie katseid takistada Nomadi püsivatest skaleerimiskatsetest vastas Nomad, et ta ei lõpeta skaleerimist ega tee midagi muud. "Ma olen väsinud, ma lähen." Ja ta keeras end kokku.
Loomulikult proovisin sama teha ka Kubernetesega. Kubernetes polnud üheteistkümne miljardi kaunaga rahul, ütles ta: "Ma ei saa. Ületab sisemised suukaitsed." Aga 1 000 000 000 kauna võiks.
Vastuseks ühele miljardile ei tõmbunud Kuub endasse tagasi. Ta hakkas tõesti skaleerima. Mida edasi protsess läks, seda rohkem kulus tal aega uute kaunade loomiseks. Kuid protsess jätkus ikkagi. Ainus probleem on selles, et kui ma saan oma nimeruumis piiramatult käivitada podisid, siis isegi ilma taotluste ja piiranguteta saan mõne ülesandega käivitada nii palju podi, et nende ülesannete abil hakkavad sõlmed mälus, protsessoris kokku tulema. Kui käivitan nii palju kausid, peaks nendest saadav teave minema salvestusruumi, st jne. Ja kui sinna jõuab liiga palju teavet, hakkab salvestusruum liiga aeglaselt tagasi tulema – ja Kubernetes hakkab tuhmiks muutuma.
Ja veel üks probleem... Teatavasti pole Kubernetese juhtelemendid üks keskne asi, vaid mitu komponenti. Eelkõige on kontrollerihaldur, planeerija jne. Kõik need poisid hakkavad samal ajal tegema tarbetut ja rumalat tööd, mis aja jooksul võtab üha rohkem aega. Kontrolleri haldur loob uued kaustad. Planeerija proovib leida neile uue sõlme. Suure tõenäosusega saavad teie klastri uued sõlmed peagi otsa. Kubernetese klaster hakkab töötama üha aeglasemalt.
Kuid otsustasin minna veelgi kaugemale. Nagu teate, on Kubernetes selline asi, mida nimetatakse teenuseks. Noh, vaikimisi töötab teenus teie klastrites tõenäoliselt IP-tabelite abil.
Kui kasutate näiteks ühte miljardit kausta ja kasutate seejärel skripti, et sundida Kubernetist uusi teenuseid looma:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Kõigis klastri sõlmedes luuakse ligikaudu samaaegselt üha rohkem uusi iptablesi reegleid. Lisaks luuakse iga teenuse jaoks miljard iptablesi reeglit.
Kontrollisin kogu seda asja mitme tuhande, kuni kümne pealt. Ja probleem on selles, et juba sellel lävel on üsna problemaatiline sõlmele ssh-d teha. Kuna paketid, mis läbivad nii palju ahelaid, ei tundu eriti head.
Ja ka see kõik lahendatakse Kubernetese abiga. Selline Ressursi kvoodi objekt on olemas. Määrab klastri nimeruumi jaoks saadaolevate ressursside ja objektide arvu. Kubernetese klastri igas nimeruumis saame luua yamli objekti. Seda objekti kasutades saame öelda, et meil on sellele nimeruumile eraldatud teatud arv päringuid ja limiite ning siis saame öelda, et selles nimeruumis on võimalik luua 10 teenust ja 10 kausta. Ja üksik arendaja võib end õhtuti vähemalt lämmatada. Kubernetes ütleb talle: "Te ei saa oma kaunasid selle summani skaleerida, kuna ressurss ületab kvooti." See on kõik, probleem lahendatud. .
Sellega seoses kerkib esile üks problemaatiline punkt. Tunnete, kui keeruliseks on Kubernetesis nimeruumi loomine muutumas. Selle loomiseks peame arvestama paljude asjadega.
Ressursikvoot + piirvahemik + RBAC
• Loo nimeruum
• Loo sees piirang
• Loo ressursikvoodi sees
• Looge CI jaoks teeninduskonto
• Loo CI ja kasutajate jaoks rollide sidumine
• Valikuliselt käivitage vajalikud hoolduspulgad
Seetõttu kasutan võimalust oma arenguid jagada. On olemas selline asi, mida nimetatakse SDK-operaatoriks. See on viis, kuidas Kubernetese klaster saab sellele operaatoreid kirjutada. Saate kirjutada avaldusi kasutades Ansible.
Algul kirjutati see Ansible'is ja siis vaatasin, et seal on SDK operaator ja kirjutasin Ansible rolli ümber operaatoriks. See avaldus võimaldab teil luua Kubernetese klastris objekti, mida nimetatakse käsuks. Käsu sees võimaldab see kirjeldada selle käsu keskkonda yamlis. Ja meeskonnakeskkonnas võimaldab see meil kirjeldada, et eraldame nii palju ressursse.
Vähe .
Ja kokkuvõtteks. Mida selle kõigega peale hakata?
Esiteks. Podi turvapoliitika on hea. Ja hoolimata asjaolust, et ükski Kubernetese installija ei kasuta neid tänaseni, peate neid siiski oma klastrites kasutama.
Võrgupoliitika ei ole lihtsalt üks mittevajalik funktsioon. See on see, mida klastris tõesti vaja läheb.
LimitRange/ResourceQuota – on aeg seda kasutada. Hakkasime seda kasutama juba ammu ja olin pikka aega kindel, et kõik kasutavad seda. Selgus, et see on haruldane.
Lisaks sellele, mida ma raportis mainisin, on ka dokumenteerimata funktsioone, mis võimaldavad teil klastrit rünnata. Ilmunud hiljuti .
Mõned asjad on nii kurvad ja haiget tekitavad. Näiteks võivad Kubernetese klastri kuubikud teatud tingimustel anda warlocksi kataloogi sisu volitamata kasutajale.
Seal on juhised selle kohta, kuidas kõike, mida ma teile ütlesin, reprodutseerida. Seal on failid tootmisnäidetega selle kohta, kuidas ResourceQuota ja Pod Security Policy välja näevad. Ja seda kõike saab puudutada.
Tänud kõigile.
Allikas: www.habr.com