Kattime Kubernetes'i klastri auke. Ettekanne ja transkriptsioon DevOpsConf'ist

Pavel Selivanov, Southbridge lahenduste arhitekt ja Slёрm'i õpetaja, esines DevOpsConf 2019 konverentsil ettekandega. See ettekande on osa süvitsi mineva kursuse teemadest Kubernetes'e kohta "Slёрm Mega".

Slёрm Basic: sissejuhatus Kubernetes'sse toimub Moskvas 18-20. novembril.
Slёрm Mega: piilume Kubernetes'e masinasse — Moskvas, 22-24. novembril.
Slёрm Online: mõlemad kursused Kubernetes'e kohta on alati saadaval.

Allpool — ettekande dekodeerimine.

Tere päevast, kolleegid ja nende toetajad. Täna räägin ma turvalisusest.

Ma näen, et saalis on täna palju turbeeksperte. Vabandan ette, kui kasutan turvamaailmast termineid, mis ei pruugi teie jaoks harjumuspäraselt kõlada.

Nii juhtus, et umbes pool aastat tagasi sattus mulle kätte üks avalik Kubernetes'i klaster. Avalik — tähendab, et seal on n-ö erinevad namespaces, kus on kasutajad, kes on isoleeritud oma namespaces. Kõik need kasutajad kuuluvad erinevatele ettevõtetele. Eeldati, et seda klastrit tuleb kasutada CDN-ina. See tähendab, et teile antakse klaster, antakse sinna kasutaja, tulete oma namespace'i, ja panne oma esiküljed üles.

Minu eelmisel ettevõttel oli sama teenus müügis. Mind paluti katsetada klastrit, et näha, kas selline lahendus sobib või mitte.

Sisenesin sellesse klastrisse. Mul anti piiratud õigused, piiratud namespace. Seal mõisteti, mis on turvalisus. Nad lugesid, mis on Kubernetes'e Role-based access control (RBAC) — ja seadistati nii, et ma ei saanud pod'e eraldi käivitada déployement'itest. Ei mäleta, millist ülesannet ma püüdsin lahendada, kui üritasin käivitada pod'i ilma déployement'ita, aga ma tõeliselt tahtsin lihtsalt pod'i käivitada. Otsustasin õnne nimel vaadata, millised õigused mul klastris on, mida ma saan teha, mida mitte, ja mida nad seal seadistanud on. Samuti räägin, mis neil RBAC-s valesti on seadistatud.

Nii juhtus, et kahe minuti pärast sain admini õigused nende klastrisse, vaatasin kõikidesse naaber-namespacetesse, nägin seal jooksmas tootmisfrontide ettevõtteid, kes olid juba teenuse ostnud ja déployinud. Ma pidin end vaevu tagasi hoidma, et mitte kellelegi fronti minna ja peamise lehe alla mingit roppust panna.

Kannan näidete abil, kuidas ma seda tegin ja kuidas sellest end kaitsta.

Aga kõigepealt tutvustan end. Minu nimi on Pavel Selivanov. Olen ettevõtte Southbridge arhitekt. Tunnen hästi Kubernetes, DevOpsi ja igasuguseid uusi trende. Meie insenerid Southbridge'is arendavad neid süsteeme ning mina annan nõu.

Lisaks oma põhitegevusele käivitasime hiljuti projektid, mida nimetame SLErroriteks. Püüame oma oskusi Kubernetesega tuua laiemale publikule, õpetades inimesi ka K8s-iga töötama.

Millest ma täna räägin. Ettekande teema on ilmselge – Kubernetes'i klastri turvalisus. Kuid tahan kohe öelda, et see teema on väga ulatuslik — seetõttu tahan kohe selgelt öelda, millest ma ei kavatse rääkida. Ma ei räägi kulunud mõistetest, mis on internetis juba sada korda läbi käidud, nagu RBAC ja sertifikaadid.

Ma räägin sellest, mis muretseb mind ja mu kolleege Kubernetes'i klastri turvalisuse osas. Me näeme neid probleeme nii Kubernetes'i klastrite pakkujates kui ka klientides, kes meie juurde tulevad. Ja ka klientides, kes tulevad meile teistest nõustamisettevõtetest. See tähendab, et tragöödia ulatus on tegelikult väga suur.

Kolm põhipunkti, millest ma täna räägin:

1. Kasutajate õigused vs pod'ide õigused. Kasutajate ja pod'ide õigused ei ole sama asi.
2. Klastri teabe kogumine. Näitan, et saame koguda kogu vajaliku teabe klassdist, ilma et meil oleks eraldi õigusi.
3. DoS-rünnak klassdile. Kui me ei suuda teavet koguda, saame siiski klasse toimetada. Räägin DoS-rünnakutest klastri halduskomponentidele.

Veel üks üldine asi, millest ma mainin — millega ma seda kõike testisin, mille kohta ma kindlasti võin öelda, et kõik töötab.

Aluseks võtame Kubernetes klastrite seadistamise Kubespray abil. Kui keegi ei tea, siis see on tegelikult rollide kogum Ansible'ile. Kasutame seda pidevalt töös. Hea selle juures on see, et saame selle igale poole peale panna — nii riistvarale kui ka kuhugi pilve. Üks installerimisviis sobib põhimõtteliselt kõikjale.

Selles klastris on mul Kubernetes v1.14.5. Kogu kubernerite klaster, mida kaalume, on jagatud nimedevaheks (namespace), kus iga nimedevahe kuulub eraldi meeskonnale ning igal meeskonnaliikmel on ligipääs oma nimedevahe. Nad ei saa minna teistesse nimedevahesesse, ainult oma. Kuid on olemas adminni konto, millel on õigused kogu klastrile.

Lubasin, et esimesena saame adminni õigused klastris. Me vajame spetsiaalselt ette valmistatud podi, mis purustab Kubernetes'e klastri. Kõik, mida peame tegema, on see rakendada Kubernetes'e klastrisse.

kubectl apply -f pod.yaml

See pod jõuab meile ühele Kubernetes'e klastrite kõrgemale masinale. Ja klaster toob meile pärast seda rõõmuga tagasi faili nimega admin.conf. Kubernerites on selle failis talletatud kõik adminni sertifikaadid ja seadistatud klastrite API. Nii lihtne on saada adminni ligipääs , arvan, et 98% Kubernetes'e klastritest.

Kordan, et selle podi tegi üks arendaja teie klastris, kellel on ligipääs oma ettepanekute juurutamiseks ühes väikeses nimedevahes, ta on täielikult piiratud RBAC. Tal ei olnud mingeid õigusi. Siiski tagastati sertifikaat.

Nüüd räägime spetsiaalselt ettevalmistatud podist. Käivitame selle igasuguste kujutistega. Näiteks võtame debian:jessie.

Meil on selline asi:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

Mis on toleration? Kuberneete klastris on meistrid tavaliselt märgitud asjaga, mida nimetatakse taint ('mürg' inglise keeles). Selle «mürgi» põhisisu on see, et meistrinodele ei saa pod'e määrata. Kuid keegi ei takista igal pod'il märkida, et ta on «mürgile» talutav. Toleration jaotis ütleb just seda, et kui mõnel nodil on NoSchedule, siis meie pod on sellise mürgiga talutav — ja ei tekki mingeid probleeme.

Edasi liikudes, me ütleme, et meie pod ei ole lihtsalt talutav, vaid soovib spetsiaalselt minna meistrile. Sest meistrites asub kõige maitsvam asi, mida me vajame — kõik sertifikaadid. Seetõttu me ütleme nodeSelector — ja meil on standardne silt meistrites, mis võimaldab valida kõigist klastrinodidest just need nodid, mis on meistrid.

Just nende kahe jaotisega jõuab pod kindlasti meistrile. Ja tal lubatakse seal elada.

Kuid lihtsalt meistrile tulles ei piisa. See ei anna meile midagi. Seetõttu on meil kaks olulist aspekti:

hostNetwork: true 
hostPID: true 

Me täpsustame, et meie pod, mille me käivitame, elab tuuma nimeteenuses, võrgunimeteenuses ja PID nimeteenuses. Niipea kui pod käivitub meistril, näeb ta kõiki selle sõlme reaalseid, töötavaid liidesi, kuulab kogu liiklust ja näeb kõiki protsesside PID-sid.

Edasi on vaid väike asi. Võtate etcd ja loete, mida soovite.

Kõige huvitavam on see Kubernetes'i funktsioon, mis seal vaikimisi olemas on.

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

Ja selle mõte on see, et me võime podis, mille me käivitame, isegi ilma õigusteta sellele klastrile, öelda, et soovime luua hostPath tüüpi mahutit. See tähendab, et võtame tee hostist, millel me käivitume — ja kasutame seda mahutina. Ja kui edasi nimetame selle name: host. Kogu see hostPath monteeritakse podi sisse. Antud näites vahemikku /host.

Kordan veel kord. Me ütlesime podile tulla meistrisse, saada seal hostNetwork ja hostPID — ja kogu meistri juur monteeritakse selle podi sisse.

Te mõistate, et Debianis töötab meil bash ja see bash töötab meie juures rootina. See tähendab, et saime just root-õigused meistrile, omamata samas mingeid õigusi Kuberneteses.

Edasi on kogu ülesanne minna konteinerisse kausta /host/etc/kubernetes/pki, kui ma ei eksi, ja võtta sealt kõik klastrite meistrisertifikaadid, et vastavalt saada klastrihalduriks.

Kui sellele lahku vaadata, on need ühed kõige ohtlikumad õigused konteinerites — olenemata kasutaja õigustest:

Kui mul on õigused konteinerite käivitamiseks mõnes klastrinimi ruumis, siis on sellel konteineril need õigused vaikimisi olemas. Ma saan käivitada privileegitud konteinerid, mis tähendab sisuliselt kõiki õigusi, praktiliselt root-õigused sõlmes.

Minu lemmik on Root kasutaja. Aga Kubernetesi jaoks on olemas võimalus Run As Non-Root. See on nagu kaitse häkkerite eest. Kas teate, mis on "moldova viirus"? Kui te olete kogemata häkker ja olete tulnud minu Kubernetesi klastrisse, siis palume me, vaesed administraatorid: "Palun märkige oma podides, millega te minu klastrit häkkida plaanite, run as non-root. Sest muidu võib juhtuda, et käitate protsessi oma podis rootina ja on väga lihtne mind häkkida. Palun kaitske end ise."

Host path volume — minu arvates kõige kiirem viis soovitud tulemuse saavutamiseks Kubernetesi klastrist.

Aga mida kõigega selle teete?

Mõtted, mis peaksid tulema igale normaalsele administraatorile, kes kohtub Kubernetesega: "Ah, ma ütlesin, Kubernetesi ei tööta. Seal on augud. Ja kogu asi on jama." Tegelikult on olemas selline asi nagu dokumentatsioon, ja kui sinna vaadata, siis seal on jagu Pod Security Policy.

See on selline yaml-objekt, mida saame luua Kubernetes'i klastri raames, mis kontrollib turvaaspekte just pod'ide määratlemisel. See tähendab, et see kontrollib õigusi kasutada erinevaid hostNetwork, hostPID ja teatud tüüpi volume, mis on pod'ides käivitamisel. Pod Security Policy abil saab kõike seda kirjeldada.

Pod Security Policy kõige huvitavam osa on see, et Kubernetes'i klastri kõik PSP-d pole lihtsalt kirjeldatud, vaid need on vaikimisi välja lülitatud. Pod Security Policy lubatakse admission plugin'i abil.

Nii et juurutame klastri Pod Security Policy, ütleme, et meil on teatud teenus pod'id nimetehnikas, millele pääsevad ligi ainult adminnid. Ütleme, et kõigil teistel pod'idel on piiratud õigused. Sest tõenäoliselt pole arendajatele vaja teie klastris privileegitud pod'e käivitada.

Ja tundub, et kõik on hästi. Meie Kubernetes'i klastrit ei saa kahe minuti jooksul häkkida.

Kuid probleem on. Tõenäoliselt, kui teil on Kubernetes'i klaster, siis on sellesse installitud jälgimissüsteem. Ma julgen isegi ennustada, et kui teie klastri jälgimise süsteem on olemas, siis see on nimega Prometheus.

See, mida ma praegu rääkima hakkan, kehtib nii Prometheus-operatori kui ka puhta Prometheuse kohta. Küsimus on selles, et kui ma ei suuda klastrisse administraatorit nii kiiresti saada, siis tähendab see, et pean rohkem otsima. Ja ma saan otsida teie jälgimise abil.

Tõenäoliselt on kõik lugenud samu artikleid Habr's ja jälgimine asub nimiruumis monitoring. Helm chart on kõigil enam-vähem sama nimega. Eeldan, et kui teete helm install stable/prometheus, siis on teil umbkaudu sama nimed. Ja tõenäoliselt ei pea ma teie klastris DNS-nime ära arvama. Sest see on standardne.

Edasi on meil mingi dev ns, kus saab käivitada mingit podi. Ja sealt podist on väga lihtne teha järgmist:

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics on üks Prometheuse eksportija, mis kogub mõõdikuid Kubernetes'i API-st. Seal on väga palju andmeid selle kohta, mis teil klastris on käimas, millised need on ja millised probleemid teil nende tegemisega on.

Lihtsaks näiteks:

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:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b»} 1

Lihtsa curl päringu tegemisega privileegideta podist saad sellist teavet. Kui te ei tea, millises versioonis Kubernetes on käivitatud, siis see räägib teile selle lihtsalt.

Ja kõige huvitavam on see, et lisaks sellele, et te pöördute kube-state-metrics'i poole, võite samal ajal pöörduda ka Prometheus'e poole otse. Te saate sealt koguda mõõdikud. Te võite isegi ehitada sealt mõõdikud. Teoreetiliselt võite koostada sellise päringu klastrist Prometheus'e suunas, mis lihtsalt sulgeb selle. Ja teie jälgimine peatub täielikult klastrist.

Ja nüüd tekib küsimus, kas mõni väline jälgimine jälgib teie jälgimist. Just nüüd sain ma võimaluse tegutseda Kubernetes'i klastris ilma mingite tagajärgedeta. Te isegi ei saa teada, et ma seal tegutsen, kuna jälgimist ei ole enam.

Sarnaselt PSP-le võib tunduda, et probleem on selles, et kõik need moodsad tehnoloogiad – Kubernetes, Prometheus – lihtsalt ei toimi ja on täis vigu. Tegelikult ei ole see nii.

On selline asi nagu – Network Policy.

Kui olete normaalne administraator, siis tõenäoliselt teate Network Policy-st, et see on järjekordne yaml, mida klastris on ja nii palju. Ja Network Policies pole kindlasti vajalikud. Ja isegi kui olete lugenud, mis on Network Policy, et see on Kubernetes'i yaml-tulemüür, mis võimaldab piirata juurdepääsu namespace'de vahel, pod'ide vahel, siis olete kindlasti otsustanud, et yaml-formaadis tulemüür Kubernetes'is on järgmiste abstraktsioonide peal… Ei-ei. See pole tõeliselt vajalik.

Isegi kui teie turbespetsialistidele ei ole räägitud, et teie Kubernetesega saab väga lihtsalt ja mugavalt tulemüüri luua, seejuures väga granuleeritud. Kui nad ei tea seda veel ja ei küsi teilt: „Noh, andke, andke…“ Igal juhul on Network Policy teil vajalik, et sulgeda juurdepääs teatud teeninduskohtadele, mis teie klastrist on võimalik külastada ilma mingisuguse volituse olemasoluta.

Nagu eespool mainitud, saab kube state metricsi tõmmata mistahes Kubernetes'i klastris asuvast nimiruumist, omamata selleks mingeid õigusi. Võrgupoliitikad on blokeerinud juurdepääsu kõikidest teistest nimiruumidest jälgimisnimiruumi ja nagu niisugune: puudub juurdepääs, puuduvad probleemid. Kõikides chartides, olgu need siis tavaline Prometheus või see, mis on operaatori kaudu, on helm'i väärtustes lihtsalt võimalus lihtsalt sisse lülitada võrgupoliitikad nende jaoks. Lihtsalt tuleb sisse lülitada ja need hakkavad töötama.

Siin on tõesti üks probleem. Normaalne administraator oleks tõenäoliselt otsustanud, et võrgupoliitikad ei ole vajalikud. Lugedes igasuguseid artikleid platformidelt nagu Habr, otsustasite, et flannel, eriti host-gateway režiimis, on parim, mida valida saate.

Mis teha?

Saate proovida ümber paigaldada oma Kubernetes klastris olevat võrgu lahendust ja asendada see millegagi funktsionaalsemaga. Näiteks sama Calico. Kuid tahan kohe öelda, et võrgu lahenduse vahetamine töötavas Kubernetes klastris on üsna keeruline ülesanne. Olen seda kaks korda lahendanud (mõlemal korral teoreetiliselt), kuid isegi Slõrvadel näitasime, kuidas seda teha. Meie õpikutes näitasime, kuidas vahetada võrgu lahendust Kubernetes klastris. Ühesõnaga, võite proovida teha nii, et tootmisklastri puhul ei tekiks katkestusi. Kuid tõenäoliselt ei õnnestu teil see.

Ja probleem lahendatakse tegelikult väga lihtsalt. Klaster sisaldab sertifikaate, ja teate, et teie sertifikaadid aeguvad aasta pärast. Tavaline lahendus sertifikaatide puhul klastris on see, et meil pole põhjust muretseda — me tõstame üles uue klastri, vanas lastakse lihtsalt aeguda, ja seejärel kõik paigaldame ümber. Tõsi, kui see aegub, võib meil nädal aega asjad seisma jääda, aga vähemalt on uus klaster.

Kui tõstate üles uue klastri, pange ka Calico asemele flannel.

Mida teha, kui teil on sertifikaadid, mis on väljastatud sadaks aastaks ja te ei kavatse klastrit ümber paigutada? On olemas selline asi nagu Kube-RBAC-Proxy. See on väga lahe areng, mis võimaldab end integreerida sidecar konteinerina igasse pod'i Kubernetes klastris. Ja see tegelikult lisab sellele pod'ile autentimise läbi Kubernetes'e RBAC-i.

Üks probleem on. Varasemalt oli Prometheuse operaatoris see lahendus Kube-RBAC-Proxy sisse ehitatud. Kuid siis seda enam ei olnud. Praegused versioonid toetuvad sellele, et teil on olemas võrgu poliitika ja saate neid kasutades sulgeda. Seetõttu tuleb veidi chart'u ümber kirjutada. Kui te sitouute sellesse repositooriumi, seal on näited, kuidas seda sidecar'idena kasutada, ja chardi tuleb minimaalselt ümber kirjutada.

On veel üks väike probleem. Mitte ainult Prometheus ei edasta oma mõõdikuid kellelegi. Kõik Kubernetes klastri komponendid oskavad samuti oma mõõdikuid edastada.

Aga nagu ma juba ütlesin, kui ei saa juurdepääsu klastrile ja teavet koguda, siis vähemalt saab kahju teha.

Nii et ma näitan kiiresti kahte viisi, kuidas Kubernetes klastrit kahjustada.

Te naerate, kui ma seda räägin, need on kaks tõelist juhtumit.

Esimene viis. Ressursside ammendumine.

Käivitame veel ühe spetsiaalse poodi. Sellel on selline osa.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

Nagu te teate, on requests see arv CPU ja mälu, mis hostis reserveeritakse konkreetsete podide jaoks, millel on requests. Kui meil on neljatuumaline host Kubernetes klastris ja sinna tuleb pod, millel on neli CPU requests, siis ei saa sinna rohkem pod'e sellel hostil olla.

Kui ma käivitada sellise poodi, siis teen käsu:

$ kubectl scale special-pod --replicas=...

Siis ei saa keegi enam Kubernetes klastrisse deployida. Sest kõigil nodidel saavad requests otsa. Ja niimoodi ma peatan teie Kubernetes klastrit. Kui ma seda õhtul teen, siis võin deploy'id üsna pikaks ajaks peatada.

Kui vaatame veel kord Kubernetes'i dokumentatsiooni, siis märkame seal mõistet, mida nimetatakse Limit Range. See seab ressursside piirangud klastrite objektidele. Saate kirjutada yaml-faili Limit Range objekti, rakendada selle teatud namespace'idesse — ja pärast saate öelda, et antud namespace'is on podide jaoks vaikimisi, maksimaalsed ja minimaalsed ressursid.

Sellise lahenduse abil saame piirata kasutajaid konkreetsetes toote namespace'ides, sundides nende podide ressursinõudeid vähem rikastama. Kuid kahjuks, isegi kui ütlete kasutajale, et nad ei tohi käivitada pod'e, mille nõuded ületavad ühte CPU-d, on olemas selline tore käsk scale, või nad saavad seda teha ka läbi dashboadi.

Ja siit tulebki teine meetod. Käivitame 11 111 111 111 111 pod'i. See tähendab üksteist miljardit. See ei ole sellepärast, et ma sellist numbrit välja mõtlesin, vaid kuna ma ise olen seda näinud.

Tõeline lugu. Hilja õhtul, kui ma juba kontorist lahkuma valmis olin, nägin, et nurga taga istus grupp arendajaid ja tegelesid millegagi oma sülearvutites. Astusin poisid juurde ja küsisin: „Mis teiega juhtus?”

Veidi varem, kell 9 õhtul, kavatses üks arendajatest koju minna. Ja otsustas: "Ma skaleerin oma rakendust nüüd ühele." Vajutas ühte, kuid internet hakkas natuke tõrkeid andma. Ta vajutas veel kord ühte, ta surus ühte, klõpsas Enterile. Ta näppis kõike, millesse sai. Siis internet taastus — ja kõik hakkas skaleerima sellele numbrile.

Tõsi, see lugu ei toimunud Kuberneteses, toona oli see Nomad. See lõppes sellega, et tunni jooksul meie katsetest peatada Nomad selle järjepidevatest skaleerimise katsetest vastas Nomad, et skaleerimist ei lõpetata ja millegagi muuga tegeleda ei soovita. "Ma olen väsinud, ma lahkun." Ja sulgus.

Ma loomulikult proovisin teha sama Kuberneteses. Üksteist miljardit podi Kuberneteses ei rõõmustanud, ta ütles: "Ei saa. Ületab sisemised limiidid." Aga 1 000 000 000 podi suutis.

Üks miljard kuupi ei kadunud. See tõepoolest hakkas skaleerima. Mida kaugemal protsess edasi liikudes, seda rohkem aega kulus uute podide loomisele. Kuid protsess ikkagi jätkus. Ainuke probleem on see, et kui ma saan oma nimespatsioonis piiramatult pod'e käivitada, siis isegi ilma päringute ja piiranguteta võin ma käivitada nii palju pod'e, et nende kaudu hakkab mälu ja protsessori kasutuse osas node'de potentsiaal kuhjuma. Kui ma käivitada nii palju pod'e, peavad neist saadud andmed jõudma salvestisse, teisisõnu etcd-sse. Ja kui sinna jõuab liiga palju teavet, hakkab salvestis liiga aeglaselt reageerima — ja Kubernetesel hakkavad tekkima viivitused.

Ja veel üks probleem … Nagu teate, Kubernetes'i haldamise elemendid ei ole üks keskne seade, vaid mitu komponenti. Seal on eelkõige manager controller, scheduler ja nii edasi. Kõik need tegelased hakkavad samal ajal tegema ebaolulist, mõttetut tööd, mis aja jooksul hakkab võtma järjest rohkem ja rohkem aega. Manager controller loob uusi pod'e. Scheduler püüab neile leida uut sõlme. Uued sõlmed teie klastris on tõenäoliselt varsti otsas. Kubernetes'i klaster hakkab töötama järjest aeglasemalt.

Aga ma otsustasin minna veel kaugemale. Nagu te teate, on Kubernetes'is selline asi nagu teenus. Ja tõenäoliselt töötab teie klastrites teenus vaikimisi IP tabelite kaudu.

Kui käivitada näiteks miljard pod'i ja seejärel sundida Kubernetes'it looma uusi teenuseid skripti abil:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

Klastri kõikidel sõlmedel genereeritakse umbes samal ajal pidevalt uusi iptables reegleid. Iga teenuse jaoks genereeritakse miljard iptables reeglit.

Olen seda kontrollinud paaril tuhandel, kuni kümneni. Probleem on selles, et juba selle piiri peal on ssh-le sõlmele ligipääs üsna keeruline. Kuna paketid, läbides sellise arvu ahelate kaudu, hakkavad end mitte väga hästi tundma.

Seda saab lahendada ka Kubetnetese abil. Seal on selline objekt nagu Resource quota. See määrab neespäisale saadaval olevate ressursside ja objektide arvu klastri sees. Saame luua yaml objekti igas Kubetnetese neespäisalas. Selle objekti abil saame öelda, et meil on selle neespäisa jaoks määratud kindel hulk päringuid, limite ja edasi saame öelda, et selles neespäisas on võimalik luua 10 teenust ja 10 poodi. Ja arendaja saab vaid koguda õhtuti. Kubetnetes ütleb talle: 'Teie poode ei ole võimalik kasvatada sellesse hulka, kuna see ületab ressursside kvota.' Kõik, probleem on lahendatud. Dokumentatsioon siin.

Üks probleemne moment seondub sellega. Tunnete, kui keeruliseks muutub nimi ruumi loomine Kuberneteses. Selle loomiseks peame arvestama paljude faktoritega.

Ressursikvoot + Piirangute vahemik + RBAC
• Loome nimi ruumi
• Loome sisemised piirangute vahemikud
• Loome sisemised ressursikvoodid
• Loome service accounti CI jaoks
• Loome rolli sidumise CI ja kasutajate jaoks
• Soovi korral käivitame vajalikud teeninduspodid

Seega, kasutades võimalust, sooviksin jagada oma arendusi. On olemas selline asi, mida nimetatakse operaatori SDK-ks. See on viis kirjutada Kuberneteses operaatorite jaoks. Saate kirjutada operaatorid Ansible'i abil.

Alguses oli see kirjutatud Ansible'is ja siis vaatasin, et olemas on operaatori SDK, ja kirjutasin Ansible'i rolli operaatoriks üle. See operaator võimaldab luua Kuberneteses objekti, mida nimetatakse käsuks. Käsu sees lubab see kirjeldada YAML-is keskkonda sellele käsule. Ja käsu keskkonnas lubab see kirjeldada, kui palju ressursse me eraldame.

Väike kergendus kogu selle keerulise protsessi jaoks.

Ja lõpetuseks. Mida kõigega sellel teha?
Esiteks. Pod Security Policy on hea. Ja kuigi ükski Kubernetes'e paigaldaja ei kasuta neid siiani, on oluline neid siiski oma klastrites rakendada.

Network Policy ei ole lihtsalt veel üks tarbetu funktsioon. See on midagi, mida kluster tõeliselt vajab.

LimitRange/ResourceQuota — aeg oleks need kasutusele võtta. Me oleme neid juba pikka aega kasutanud ja ma olin kindel, et kõik kasutavad neid, aga selgus, et see on haruldus.

Lisaks sellele, millest ma oma ettekandes rääkisin, on olemas dokumenteerimata funktsioonid, mis võimaldavad klastrit rünnata. Hiljuti ilmus suur analüüs Kubernetes'e haavatavustest..

Mõned asjad on nii kurvad ja häirivad. Näiteks võivad Kubernetes'e klastris teatud tingimustel kubeletid kinkida warlocks kausta sisu volitamata kasutajale.

Siin Seal on juhised, kuidas reprodutseerida kõike, millest ma rääkisin. Seal on failid tootmisnäidistega, kuidas ResourceQuota ja Pod Security Policy välja näevad. Ja seda kõike saab katsetada.

Aitäh kõigile.

Allikas: habr.com