Täidame Kubernetes klastris esinevaid puudujääke. Ettekanne ja tõlge DevOpsConfilt.

Pavel Selivanov, lahenduste arhitekt Southbridge'is ja Slurma õpetaja, esitles ettekannet DevOpsConf 2019. See ettekand on osa süvainte kursusest Kubernetes "Slurma Mega".

Slurma Baas: sissejuhatus Kubernetesesse toimub Moskvas 18.-20. novembril.
Slurma Mega: vaatame Kubernetes'e kapoti alla — Moskvas, 22.-24. novembril.
Slurma Veebis: mõlemad kursused Kubernetesest saadaval igal ajal.

Allpool — ettekande ülevaade.

Tere päevast, kolleegid ja tõrjujad. Täna räägin ma turvalisusest.

Näen, et saalis on täna palju turvaeksperte. Vabandan ette, kui kasutan turvamaailmast termineid, mis ei pruugi teie jaoks tuttavad olla.

Nii juhtus, et umbes kuus kuud tagasi sattusin ma ühte avalikku Kubernetes'e klastrisse. Avalik — tähendab, et seal on n-ö erinevad namespaces, milles on kasutajad, kes on oma namespaces eraldi. Kõik need kasutajad kuuluvad erinevatesse ettevõtetesse. Eeldati, et seda klastrit kasutatakse CDN-ina. See tähendab, et teile antakse klaster, antakse sinna kasutaja, te tulete oma namespace'i, deponeerite oma esindused.

Minu endisele ettevõttele püüti sellist teenust müüa. Ja mind paluti uurida, kas see lahendus sobib või mitte.

Läksin ma selle klastrisse. Mul anti piiratud õigused, piiratud namespace. Seal olid inimesed, kes mõistsid, mis on turvalisus. Nad olid lugenud, mis on Kubernetes'e põhine juurdepääsu kontroll (RBAC) — ja nad olid selle seadnud nii, et ma ei saanud käitada pod'e eraldi deployement'idest. Ei mäleta, missugust ülesannet ma üritasin lahendada, käitades pod'i ilma deployement'ita, aga mulle väga meeldis lihtsalt pod'iga katsetada. Otsustasin juhuslikult uurida, mis õigused mul klastris on, mida ma saan ja mida mitte, mida nad seal kokku keeranud olid. Ühtlasi räägin, mis on nende RBAC-is valesti seadistatud.

Nii juhtus, et kahe minuti pärast sain adminni õigused nende klastrisse, vaatasin kõiki naaber namespaces'e, nägin seal töötavaid tootmisfrontte ettevõtetelt, kes olid juba teenuse ostnud ja oma asjad üles seadnud. Pidin end vaevu tagasi hoidma, et mitte kellegi veebilehe esilehele sobitada mõnda roppust.

Räägin näidete abil, kuidas ma seda tegin ja kuidas sellise asja eest kaitsta.

Aga alustuseks tutvustan end. Minu nimi on Pavel Selivanov. Olen Southbridge'i arhitekt. Ma oskan Kubernetesest, DevOpsist ja muudest trendikatest asjadest rääkida. Koos Southbridge'i inseneridega ehitame me seda kõike, mina teen konsultatsioone.

Peale põhitegevuse oleme hiljuti käivitanud projektid, mida nimetatakse Slörmideks. Me proovime oma oskusi Kuberneteses natuke laiemalt jagada, õpetada teisi inimesi ka K8s-iga töötama.

Millest ma täna räägin. Esitluse teema on ilmne — Kubernetes'i klastrite turvalisus. Kuid tahan kohe öelda, et see teema on väga suur — ja seetõttu tahan kohtuda nende punktidega, millest ma kindlasti ei räägi. Ma ei hakka rääkima kulunud terminoloogiatest, mis on internetis juba sada korda läbi vaieldud. Kõik sellised RBAC'id ja sertifikaadid.

Räägin sellest, mis muret teeb mulle ja mu kolleegidele Kubernetes'i klastrite turvalisuses. Näeme neid probleeme nii Kubernetese klastreid pakkuvatelt teenusepakkujatelt kui ka klientidelt, kes meile pöörduvad. Ja isegi klientidelt, kes tulevad meile teistelt konsultatsioonihaldusettevõtetelt. Seega, tragöödia ulatus on tegelikult väga suur.

Kokku kolm punkti, millest ma täna räägin:

1. Kasutajate õigused vs pod'ide õigused. Kasutajate õigused ja pod'ide õigused — see pole sama asi.
2. Teabe kogumine klastrist. Näitan, et klastrist saab kogu vajaliku teabe koguda, ilma eriliste õigusteta.
3. DoS-rünnak klastrile. Kui me ei saa teavet koguda, suudame siiski klastrit kokku varistada. Räägin DoS-rünnakutest klastrite juhtkomponentide peale.

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

Võtame aluseks Kubernetes'i klastrite loomise Kubespray abil. Kui keegi ei tea, siis see on tegelikult Ansible'i jaoks mõeldud rollide kogum. Kasutame seda pidevalt töös. See on hea, sest seda saab rakendada igasugustele seadmetele — nii metallile kui ka pilve. Üks installatsiooni viis sobib igasuguste jaoks.

Selles klastris on mul Kubernetes v1.14.5. Kogu Kubase klaster, mida me vaatame, on jagatud nime ruumideks, iga nime ruum kuulub erinevale meeskonnale, ja igal meeskonna liikmel on juurdepääs oma nime ruumile. Nad ei saa siseneda teistesse nime ruumidesse, vaid ainult oma. Kuid on olemas ühe adminni konto, millel on õigused kogu klastrile.

Lubasin, et esimesena saadakse adminni õigused klastrile. Meile on vajalik spetsiaalselt ette valmistatud pod, mis lõhub Kubernetes klastrit. Kõik, mida peame tegema, on see klastrisse rakendada.

kubectl apply -f pod.yaml

See pod saabub ühe klastrite Kubernetes juhtkonda. Ja klaster tagastab meile seejärel faili nimega admin.conf. Selles failis hoitakse kõiki adminni sertifikaate ja samal ajal on seadistatud klastrite API. Nii lihtne on saada adminni juurdepääs, ma arvan, et 98% Kubernetes klastritest.

Korraks, see pod tegi üks arendaja teie klastris, kellel on juurdepääs oma ettepanekute rakendamiseks ühte väikesse nime ruumi, ta on täielikult RBAC poolt piiratud. Tal polnud mingeid õigusi. Kuid sellest hoolimata tagastati sertifikaat.

Nüüd rääkides spetsiaalselt ette valmistatud podist. Käivitame selle mis tahes pildiga. Näiteks võtame debian:jessie.

Meil on selline asi:

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

Mis on toleration? Kubernetes klastris on juhid tavaliselt märgitud asjaga, mida nimetatakse taint ("saaste" inglise keeles). Selle "saaste" mõte on see, et juhitavaid südamikke ei saa määrata podide jaoks. Kuid keegi ei takista igas podis märkida, et ta on saaste suhtes tolerantne. Toleration sektsioon ütleb just seda, et kui mõnel südamekesel on NoSchedule, siis on meie pod sellele saastele tolerantne — ja mingeid probleeme ei teki.

Edasi, me ütleme, et meie pod ei ole lihtsalt tolerantne, vaid soovib tungida spetsiaalselt juhile. Kuna juhil on kõik maitsvamad asjad, mida me vajame — kõik sertifikaadid. Seetõttu ütleme nodeSelector — ja meil on standardne label juhtidel, mis võimaldab valida kogu klastrist just need südamikud, mis on juhid.

Just selliste kahe sektsiooni puhul tuleb pod kindlasti juhile. Ja talle lubatakse seal elada.

Kuid lihtsalt juhile jõudmine ei ole piisav. See ei pruugi midagi anda. Seetõttu on meil sellised kaks asja:

hostNetwork: true 
hostPID: true 

Me märgime, et meie pod, mille me käivitame, elab kerni namespaces, network namespaces ja PID namespaces. Kui pod on masternodes käivitunud, suudab see näha kõiki tõelisi, elavaid liideseid selle nodi peal, kuulata kogu liiklust ja näha kõiki protsesside PID-sid.

Edasi on jäänud väike asi. Võtke etcd ja looge, mida soovite.

Kõige huvitavam on see, et see on Kubernetes'e võimalus, mis on seal vaikimisi olemas.

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

Ja selle olemus on see, et me saame podis, mille me käivitame, isegi ilma õigusteta sellele klastrile, öelda, et soovime luua hostPath tüüpi volume. See tähendab, et viimased teeme raja hostist, kus me käivitume — ja võtame selle volume'ina. Edasi nimetame selle name: host. Kogu hostPath monteerime podi sisse. Käesoleval juhul kausta /host.

Kordan veel kord. Me ütlesime podile tulla masternodele, saada hostNetwork ja hostPID — ning monteerida kogu master root sellesse podi.

Sa aru, et Debiani süsteemis meil töötab bash ja see bash töötab meil rootina. See tähendab, et saime just ruuti masterisse, omamata mingit õigust Kubernetes'e klastris.

Edasi on kogu ülesanne minna podisse kausta /host /etc/kubernetes/pki, kui ma ei eksi, ning võtta sealt kõik klastrimasteri sertifikaadid ja seega saada klastrihalduriks.

Kui sellesse vaadata, siis need on üheks kõige ohtlikumaks õiguseks podides — hoolimata sellest, millised õigused on kasutajal:

Kui mul on õigused käivitada pod mingis klastrinamespace'is, siis on selle podi õigused vaikimisi olemas. Ma saan käivitada privileegitud pode, mis antud juhul on kõik õigused, praktiliselt root nodi.

Minu lemmik on Root user. Ja Kubernetesel on selline valik nagu Run As Non-Root. See on nagu kaitse häkkerite eest. Kas te teate, mis on 'Moldova viirus'? Kui te olete äkki häkker ja tulite minu Kubernetes'e klastrisse, siis me, vaesed administraatorid, palume: "Palun määrake oma podides, millega te hakkate mu klastrit häkkima, run as non-root. Vastasel juhul võib juhtuda, et käivitate protsessi oma podis rootina ja teil on väga lihtne mind häkkida. Palun kaitske end ise."

Host path volume — minu arvates on see kõige kiirem viis saada soovitud tulemus Kubernetes'e klastrist.

Aga mis nendega kõigega teha?

Mõtted, mis peaksid tulema iga normaalse administraatori juurde, kes seisab silmitsi Kubernetesega: „Aha, ma ütlesin ju, et Kubernetes ei tööta. Seal on augud. Ja kogu Kubernetes on jama.“ Tegelikult on olemas selline asi nagu dokumentatsioon, ja kui sinna vaadata, siis seal on jaotis Pod Security Policy.

See on selline yaml-objekt — me saame seda luua Kubernetes'e klastris — mis kontrollib turvaaspekte just podide kirjelduses. See tähendab, et see kontrollib õigusi hostNetwork, hostPID ja teatud tüüpi volume'ite kasutamiseks, mis on podides käivitamisel. Pod Security Policy abil saab kõik need aspektid kirjeldada.

Kõige huvitavam Pod Security Policy juures on see, et Kubernetes'e klastri kõik PSP-d ei ole mitte lihtsalt kuidagi määratletud, vaid nad on vaikimisi välja lülitatud. Pod Security Policy aktiveeritakse admission plugin'i abil.

Olgu, deployime klastrisse Pod Security Policy, ütleme, et meil on teenuslikud podid mingis nimepaikuses, kuhu pääsevad ligi ainult adminnid. Ütleme, et kõigil ülejäänud podidel on piiratud õigused. Sest tõenäoliselt ei vaja arendajad teie klastris privileege äratavaid pode.

Ja meil tundub, et kõik on hästi. Ja meie Kubernetes'e klastrit ei saa kahe minutiga häkkida.

Kuid on probleem. Tõenäoliselt, kui teil on Kubernetes'e klaster, siis on teie klastris installitud jälgimine. Ma isegi julgen ennustada, et kui teie klastris on jälgimine, siis kutsutakse seda Prometheuseks.

See, mida ma praegu räägin, kehtib nii Prometheus operaatori kui ka puhta Prometheuse kohta. Küsimus on selles, et kui ma ei saa nii kiiresti administraatorit klastrisse, siis tähendab see, et pean rohkem otsima. Ja ma saan otsida oma jälgimise abil.

Tõenäoliselt on kõik lugenud samu artikleid Habr's ja jälgimine on nimepaikuses monitoring. Helm chart kõigil on enam-vähem sama nimega. Ma arvan, et kui teete helm install stable/prometheus, siis ütlete, et teil on umbes samad nimed. Ja isegi 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 mingi 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 eksportijatest, mis kogub mõõdikud Kubernetes API-st. Seal on palju andmeid selle kohta, mis on teie klastris käimas, milline see on ja 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:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989",container_id="docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b"} 1

Lihtsa curl päringu tegemine mitteprivilegeeritud podist võimaldab saada sellist teavet. Kui te ei tea, millises Kubernetes versioonis te olete, siis see räägib teile kergesti.

Ja kõige huvitavam on see, et lisaks sellele, et te pöördute kube-state-metrics poole, võite sama hästi pöörduda ka otse Prometheuse poole. Te saate sealt mõõdikud koguda. Te isegi saate sealt mõõdikud genereerida. Teoreetiliselt saate koostada sellise päringu klastrist Prometheusse, mis lihtsalt väljalülitab selle. Ja teie jälgimine lõpetab klastrist üldse töötamise.

Ja siin tekib küsimus, kas mõni väline jälgimine jälgib teie jälgimist. Just nüüd sain võimaluse tegutseda Kubernetes klastris täielikult tagajärgedeta. Te isegi ei saa teada, et ma seal tegutsemisega olen, kuna jälgimist lihtsalt ei ole.

Just nagu PSP-ga, on tunne, et probleem on selles, et kõik need moes tehnoloogiad — Kubernetes, Prometheus — nad lihtsalt ei tööta ja on täis auke. Tegelikult ei ole.

On olemas selline asi — Network Policy.

Kui te olete normaalne admin, siis tõenäoliselt teate, et Network Policy on järjekordne yaml, mida klastris on juba piisavalt. Ja Network Policies ei ole tõenäoliselt vajalikud. Ja isegi kui te lugesite, mis on Network Policy, et see on Kubernetes yaml-tuli, mis võimaldab piirata juurdepääsu õiguslikke suhteid nimede vahel, podide vahel, siis te olete kindlasti otsustanud, et yaml-formaadis tuli Kuberneteses järgmistes abstraktsioonides... Ei-ei. See ei ole kindlasti vajalik.

Isegi kui teie turbespetsialistid ei tea, et teie Kuberneteses on väga lihtne ja kerge ehitada tulemüüri, veelgi detailsemalt. Kui nad seda veel ei tea ja ei torma küsima: "No andke, andke..." Siiski on Network Policy teil vajalik, et piirata juurdepääsu teatud teenuskohtadele, millesse võib teie klastri kaudu ligipääsu saada, ilma igasuguse autoriseerimiseta.

Nagu näidatud näites, on võimalik kube state metrics'i kasutada igast nimiruumist Kuberneteses, ilma et selleks õiguseid oleks. Network policies on piiranud juurdepääsu kõigist teistest nimiruumidest jälgimise nimiruumi, ja nagu ka kõik: ei ole juurdepääsu, ei ole probleemi. Kõikides olemasolevates chartides, nii standartse Prometheuse kui ka selle Prometheuse puhul, mis on operaatoris, on lihtsalt values failis olemas valik, et aktiveerida network policies nende jaoks. Lihtsalt tuleb aktiveerida ja need hakkavad tööle.

Tõsi, siin on üks probleem. Normaalsena tavatavate adminnina on tõenäoliselt otsustanud, et network policies ei ole vajalikud. Ja lugedes igasuguseid artikleid ressurssidelt nagu Habr, otsustasite, et flannel, eriti host-gateway režiimis, on parim valik, mida saate teha.

Mida teha?

Võite proovida taastada oma Kuberneteses oleva võrgu lahenduse, proovida asendada seda millegi funktsionaalsemaga. Näiteks Calicoga. Kuid öelda tuleb, et võrgu lahenduse vahetamine töötavas Kuberneteses ei ole just triviaalne ülesanne. Olen selle kaks korda lahendanud (mõlemad korrad küll teoreetiliselt), aga meil oli isegi Slurmides näidatud, kuidas seda teha. Meie koolitatavatele näitasime, kuidas vahetada võrgu lahendust Kuberneteses. Põhimõtteliselt võite proovida teha nii, et tootmisklastris ei esineks seisakut. Kuid tõenäoliselt ei õnnestu teil midagi.

Probleemi lahendamine on tegelikult väga lihtne. Klaster sisaldab sertifikaate, ja te teate, et teie sertifikaadid lähevad aasta pärast kehtetuks. Noh, ja tavaliselt on klastris normaalne lahendus sertifikaatide puhul — miks peaksime vaeva nägema, tõstame kõrvale uue klastri, vanas laseme sellel minna, ja kõik taaskäivitame. Tõsi, kui see aegub, seisab meil päev aega, kuid selle võrra uue klastriga.

Uut klastri tõstes, asetage samal ajal Calico flanneli asemel.

Mida teha, kui teil on sertifikaadid, mis on välja antud sajaks aastaks ja te ei plaani klastrit üle deponeerida? On olemas selline asi nagu Kube-RBAC-Proxy. See on tõeliselt äge arendamine, mis võimaldab end sisestada sidecar konteinerina ükskõik millisesse pod'i Kubernetes klastris. Ja see annab tegelikult sellele pod'ile autoriseerimise läbi Kubernetes'i RBAC-i.

Üks probleem on. Varem oli Prometheuse operaatoris see Kube-RBAC-Proxy lahendus sisse ehitatud. Kuid seda pole enam. Tänapäevaste versioonide puhul lähtutakse sellest, et teil on olemas võrgu poliitika ja te sulgete nende abil. Seetõttu tuleb natuke graafikut ümber kirjutada. Tegelikult, kui te külastate seda repot, seal on näited, kuidas seda kasutada sidecar'ideena, ja graafikut tuleb minimaalselt ümber kirjutada.

On veel üks väike probleem. Mitte ainult Prometheus ei anna oma mõõtmeid kellelegi. Kõik Kubernetes klastri komponendid oskavad ka oma mõõtmeid anda.

Aga nagu ma juba ütlesin, kui te ei saa klastrile ligi ja teavet koguda, siis saate vähemalt kahjulik olla.

Seega näitan kiiresti kahte viisi, kuidas Kubernetes klastrit kahjustada.

Te naerate, kui ma seda räägin, need on kaks juhtumit reaalsest elust.

Esimene meetod. Ressursside kurnamine.

Käivitame veel ühe spetsiaalse pod'i. Sellel on selline sektsioon.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

Kuidas te teate, requests — see on see CPU ja mälu maht, mis hostis reserveeritakse konkreetsete pod'ide jaoks koos requests'iga. Kui meil on neli tuuma host Kubernetes klastris ja sinna tuleb pod, mille requests on neli CPU, siis ei saa sellele hostile enam ühtegi muud pod'i koos requests'iga tulla.

Kui ma käitan sellise pod'i, siis annan käsu:

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

Siis ei saa keegi enam Kubernetes klastrisse deponeerida. Sest kõigil sõlmedel lõppevad requests. Ja seeläbi peatan teie Kubernetes klastrit. Kui ma seda õhtul teen, siis võivad depood üsna pikaks ajaks peatuda.

Kui vaatame veel kord Kubernetes'e dokumentatsiooni, siis näeme mõistet, mida kutsutakse Limit Range'iks. See määratleb ressursid klastrielementidele. Sa saad kirjutada yaml objekti Limit Range, rakendada selle kindlatesse nimiruumi ja seejärel selle nimiruumi öelda, et sul on pod'de jaoks vaikimisi, maksimaalsed ja minimaalsed ressursid.

Selle abil saame piirata kasutajaid konkreetses tootenimiruumi meeskondade võimalustes määrata oma pod'idesse igasuguseid jama. Kuid kahjuks, isegi kui sa ütled kasutajale, et ei tohi käivitada pod'e, mille nõuded ületavad ühte CPU-d, on olemas selline imeline käsk scale, või nad võivad seda teha ka dashboardi kaudu.

Ja sealt tulebki number kaks. Käivitame 11 111 111 111 111 pod'i. See on üksteist miljardit. See ei ole sellepärast, et ma sellist numbrit välja mõtlesin, vaid seetõttu, et ma olen seda ise näinud.

Tõeline lugu. Hilisel õhtul olin juba lahkumiseks valmis. Vaatan, et nurga taga istub grupp arendajaid ja tegeleb millegagi arvutitega. Lähene ja küsin: „Mis teil juhtus?”

Veidi varem, umbes kell üheksa õhtul, olid ühe arendaja plaanid koju minna. Ta mõtles: „Ma skaleerin oma rakendust ühekohaliseks.” Vajutas ühekohale, kuid internet veidi viibis. Ta vajutas veel kord ühekohale, ta surus ühekohale, klõpsas Enter'ile. Ta proovis kõike, mis tal võimalik oli. Siis internet ärkas ellu — ja kõik hakkas skaleeruma sellele numbrile.

Tõsi, see lugu ei toimunud Kubernetes'es, tookord oli see Nomad. See lõppes sellega, et pärast tunni jagu katseid Nomad'it peatada, teatas Nomad, et ta ei lakka skaleerumast ja ei hakkagi millegagi muuga tegelema. „Ma olen väsinud, ma lahkun.” Ja sulges ennast.

Jõudsin loomulikult proovida sama teha ka Kubernetes'es. Üksteist miljardit pod'i Kubernetes mind rõõmustanud, ta ütles: „Ei saa. Ületab sise limite.” Kuid 1 000 000 000 pod'i suutis.

Vastupidiselt ei piirdunud üks miljard Pod'i endasse. Ta tõepoolest hakkas skaleeruma. Mida edasi protsess liikuda jõudis, seda rohkem aega läks uute podide loomisele. Kuid protsess jätkus. Ainuke probleem on see, et kui ma saan oma nimiruumis piiramatult pod'e käivitada, siis isegi ilma nõudmiste ja piiranguteta saan ma käivitada nii palju pod'e, et nende ülesannetega hakkavad noodid mälus ja CPU-s kokku langema. Kui ma käivitan nii palju pod'e, peab teave nendest jõudma salvestusse, nimelt etcd. Ja kui sinna jõuab liiga palju teavet, hakkab salvestus liiga aeglaselt andmeid väljastama — ja Kubernetesel algavad probleemid.

Ja veel üks probleem... Nagu te teate, Kubernetes'e juhtimisseadmed ei ole lihtsalt üks keskmine element, vaid mitu kompoonent. Seal on eriti kontrollija, ajakava jne. Kõik need tüübid hakkavad samal ajal täitma tarbetut tühist tööd, mis aja jooksul hakkab nõudma üha rohkem aega. Kontrollija hakkab uusi pod'e looma. Ajakava püüab neile leida uut nooti. Uued noodid teie klastris on tõenäoliselt varsti otsakorral. Kubernetes alustab üha aeglasemat tööd.

Kuid ma otsustasin minna veelgi kaugemale. Nagu te teate, on Kubernetes'es üks element, mida nimetatakse teenuseks. Noh, ja tõenäoliselt töötavad teie klastrites teenused IPTables'i abil.

Kui me näiteks käivitame ühe miljardi pod'i ja siis skripti abil sundida Kubernetes'e looma uusi teenuseid:

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

Klastri kõigil noodidel genereeritakse ligikaudu samal ajal järjest uusi ja uusi IPTables'i reegleid. Iga teenuse puhul genereeritakse umbes miljard IPTables'i reeglit.

Ma kontrollisin kõiki neid asju paaritel tuhandetel, kuni kümme. Ja probleem on see, et juba sellel lävel on sissetoomine SSH nooti üsna problemaatiline. Kuna paketid, läbides sellist arvu ahelaid, hakkavad end mitte väga hästi tundma.

Jah, see kõik lahendatakse Kubernetes'e abil. Seal on selline objekt nagu Resource quota. See määrab inimruumile ligipääsetavate ressursside ja objektide arvu klastri piires. Me saame luua YAML objekti igas Kubernetes'i nimiruumis. Selle objekti abil saame öelda, et antud nimiruumile on eraldatud kindel arv nõudmisi, limiite, ja edasi saame öelda, et selles nimiruumis on võimalik luua 10 teenust ja 10 konteinerit. Ja arendaja võib igal õhtul muretult puhkama minna. Kubernetes ütleb talle: „Ei, sa ei saa oma konteinereid sellisesse arvu skaleerida, kuna see ületab ressursikvooti.“ Kõik, probleem on lahendatud. Dokumentatsioon siin.

Üks probleemne hetk sellega seoses tekib. Tunnete, kui keeruliseks muutub Kubernetes'es nimiruumide loomine. Selleks, et seda luua, peame arvestama paljude asjadega.

Resource quota + Limit Range + RBAC
• Loome nimiruum
• Loome sees limitrange
• Loome sees resourcequota
• Loome serviceaccount'i CI jaoks
• Loome rolebinding'i CI ja kasutajate jaoks
• Valikuliselt käivitame vajalikud teeninduskonteinerid

Seetõttu tahan ma kasutada juhust ja jagada oma arengutegevusi. On olemas selline asi nagu operaatori SDK. See on viis kirjutada Kubernetes'e klastri jaoks operaatorite loomise võimalusi. Te saate kirjutada operaatorite abil Ansible'iga.

Esialgu oli meil kirjutatud Ansible peale, kuid hiljem vaatasin, et on olemas operaatori SDK ja tõlgendasin Ansible'i rolli operaatoriks. See operaator võimaldab meil luua Kubernetes'e klastri objekti, mida nimetatakse käsuks. Käsu sees võimaldab see YAML formaadis keskkonda selle käsu jaoks kirjeldada. Ja käsu keskkonnas võimaldab see kirjeldada, kui palju ressursse me eraldame.

Väike lihtsustaja kogu selle keerulise protsessi jaoks.

Ja lõpetuseks. Mida kõigega selle kohta teha?
Esiteks. Pod Security Policy – see on hea. Ja kuigi ükski Kubernetes'i installija ei kasuta neid siiani, on siiski teie klastrites neid vaja kasutada.

Network Policy – see ei ole lihtsalt veel üks tarbetu funktsioon. See on midagi, mis on klastri jaoks tõeliselt vajalik.

LimitRange/ResourceQuota – aeg on hakata kasutama. Me oleme juba seda kasutanud ja olin pikka aega kindel, et kõik rakendavad seda. Olin eksinud, see on haruldane.

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

Mõned asjad on nii kurvad ja solvad. Näiteks teatavatel tingimustel võivad klastris oleva kubelet'id anda warlocks kausta sisu, ja seda autoriseerimata kasutajale.

Siin seal on juhised, kuidas kõik, millest ma rääkisin, taastada. Seal on failid toodangunäidistega, kuidas ResourceQuota ja Pod Security Policy välja näevad. Ja kõike seda saab Katsuda.

Aitäh kõigile.

Allikas: habr.com