Pavel Selivanov, arhitekt rešitev Southbridge in učitelj Slurm, je imel predstavitev na DevOpsConf 2019. Ta govor je del ene od tem poglobljenega tečaja o Kubernetesu »Slurm Mega«.
poteka v Moskvi od 18. do 20. novembra.
— Moskva, 22.-24. november.
vedno na voljo.
Pod rezom je prepis poročila.
Dober dan, kolegi in tisti, ki sočustvujete z njimi. Danes bom govoril o varnosti.
Vidim, da je danes v dvorani veliko varnostnikov. Že vnaprej se vam opravičujem, če izraze iz sveta varnosti uporabljam ne tako kot je pri vas v navadi.
Zgodilo se je, da sem pred približno šestimi meseci naletel na eno javno gručo Kubernetes. Javno pomeni, da obstaja n-to število imenskih prostorov; v teh imenskih prostorih so uporabniki izolirani v svojem imenskem prostoru. Vsi ti uporabniki pripadajo različnim podjetjem. No, domnevalo se je, da je treba to gručo uporabiti kot CDN. Se pravi, dajo vam gručo, tam vam dajo uporabnika, tja greste v svoj imenski prostor, razporedite svoje fronte.
Moje prejšnje podjetje je poskušalo prodati takšno storitev. Prosili so me, naj prebodem gručo, da vidim, ali je ta rešitev primerna ali ne.
Prišel sem do tega grozda. Dobil sem omejene pravice, omejen imenski prostor. Fantje tam so razumeli, kaj je varnost. Prebrali so o nadzoru dostopa na podlagi vlog (RBAC) v Kubernetesu - in so ga zasukali tako, da nisem mogel zagnati podov ločeno od uvajanj. Ne spomnim se težave, ki sem jo poskušal rešiti z zagonom poda brez uvajanja, vendar sem res želel zagnati samo pod. Za srečo sem se odločil, da pogledam, kakšne pravice imam v grozdu, kaj smem, česa ne in kaj so tam zafrknili. Hkrati vam bom povedal, kaj so napačno konfigurirali v RBAC.
Tako se je zgodilo, da sem v dveh minutah prejel admina v njihov grozd, pogledal vse sosednje imenske prostore, videl tam tekoče proizvodne fronte podjetij, ki so storitev že kupila in postavila. Komaj sem se ustavil, da ne bi šel pred nekoga in na glavno stran dal kakšno kletvico.
Povedal vam bom s primeri, kako sem to naredil in kako se zaščititi pred tem.
Ampak najprej naj se predstavim. Moje ime je Pavel Selivanov. Sem arhitekt pri Southbridgeu. Razumem Kubernetes, DevOps in vse vrste fancy stvari. Inženirji Southbridgea in jaz gradimo vse to in svetujem.
Poleg naših glavnih dejavnosti smo pred kratkim začeli izvajati projekte Slurms. Svojo sposobnost dela s Kubernetesom poskušamo približati množicam, da naučimo tudi druge ljudi delati s K8.
O čem bom govoril danes? Tema poročila je očitna - o varnosti gruče Kubernetes. Vendar želim takoj povedati, da je ta tema zelo velika - in zato želim takoj pojasniti, o čem zagotovo ne bom govoril. Ne bom govoril o izrabljenih izrazih, ki so bili na internetu že stokrat uporabljeni. Vse vrste RBAC in certifikatov.
Govoril bom o tem, kaj mene in moje kolege boli glede varnosti v gruči Kubernetes. Te težave opažamo tako med ponudniki, ki zagotavljajo gruče Kubernetes, kot med strankami, ki prihajajo k nam. In celo od strank, ki pridejo k nam iz drugih svetovalnih administrativnih podjetij. To pomeni, da je obseg tragedije dejansko zelo velik.
Danes bom govoril o treh točkah:
- Pravice uporabnika v primerjavi s pravicami pod. Uporabniške pravice in pravice pod niso isto.
- Zbiranje informacij o grozdu. Pokazal bom, da lahko zberete vse informacije, ki jih potrebujete iz gruče, ne da bi imeli posebne pravice v tej gruči.
- DoS napad na gručo. Če ne moremo zbrati informacij, bomo v vsakem primeru lahko postavili gručo. Govoril bom o napadih DoS na nadzorne elemente gruče.
Še ena splošna stvar, ki jo bom omenil, je, na čem sem vse to testiral, na kateri lahko zagotovo rečem, da vse deluje.
Za osnovo vzamemo namestitev gruče Kubernetes s pomočjo Kubespray. Če kdo ne ve, je to pravzaprav niz vlog za Ansible. Pri svojem delu ga nenehno uporabljamo. Dobra stvar je, da jo lahko zakotališ kamor koli - lahko jo zakotališ na kose železa ali nekam v oblak. En način namestitve deluje načeloma za vse.
V tej gruči bom imel Kubernetes v1.14.5. Celotna gruča Cube, ki jo bomo obravnavali, je razdeljena na imenske prostore, vsak imenski prostor pripada ločeni ekipi in člani te ekipe imajo dostop do vsakega imenskega prostora. Ne morejo iti v različne imenske prostore, samo v svojega. Obstaja pa določen skrbniški račun, ki ima pravice do celotne gruče.
Obljubil sem, da bomo najprej pridobili skrbniške pravice za gručo. Potrebujemo posebej pripravljen pod, ki bo razbil gručo Kubernetes. Vse kar moramo storiti je, da ga uporabimo v gruči Kubernetes.
kubectl apply -f pod.yamlTa pod bo prispel do enega od mojstrov gruče Kubernetes. In po tem nam bo gruča veselo vrnila datoteko z imenom admin.conf. V Cube ta datoteka shranjuje vsa skrbniška potrdila in hkrati konfigurira API gruče. Tako preprosto je pridobiti skrbniški dostop do, mislim, 98 % gruč Kubernetes.
Ponavljam, ta sklop je izdelal en razvijalec v vaši gruči, ki ima dostop do umestitve svojih predlogov v en majhen imenski prostor, vse pa je zajel RBAC. Ni imel nobenih pravic. Toda potrdilo je bilo kljub temu vrnjeno.
In zdaj o posebej pripravljenem stroku. Zaženemo ga na kateri koli sliki. Vzemimo za primer debian:jessie.
Imamo to zadevo:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Kaj je toleranca? Masterji v gruči Kubernetes so običajno označeni z nečim, kar se imenuje taint. In bistvo te "okužbe" je, da pravi, da podov ni mogoče dodeliti glavnim vozliščem. Toda nihče se ne trudi, da bi v kateri koli stroki označil, da je tolerantna na "okužbo". Razdelek Toleration samo pravi, da če ima neko vozlišče NoSchedule, potem je naše vozlišče tolerantno na takšno okužbo - in ni težav.
Nadalje pravimo, da naš podrejeni ni samo toleranten, ampak želi tudi posebej ciljati na gospodarja. Ker imajo mojstri najbolj slastno, kar potrebujemo - vse certifikate. Zato rečemo nodeSelector - in imamo standardno oznako na masterjih, ki vam omogoča, da med vsemi vozlišči v gruči izberete točno tista vozlišča, ki so masterji.
S tema dvema razdelkoma bo zagotovo prišel do mojstra. In tam mu bo dovoljeno živeti.
A le priti k mojstru nam ni dovolj. To nam ne bo dalo ničesar. Nato imamo ti dve stvari:
hostNetwork: true
hostPID: true Določimo, da bo naš pod, ki ga zaženemo, živel v imenskem prostoru jedra, v imenskem prostoru omrežja in v imenskem prostoru PID. Ko je pod zagnan na glavnem vozlišču, bo lahko videl vse resnične vmesnike tega vozlišča v živo, poslušal ves promet in videl PID vseh procesov.
Potem gre za malenkosti. Vzemi etcd in beri kar hočeš.
Najbolj zanimiva stvar je ta funkcija Kubernetes, ki je tam privzeto prisotna.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host In njegovo bistvo je, da lahko rečemo v podu, ki ga zaženemo, tudi brez pravic do te gruče, da želimo ustvariti volumen tipa hostPath. To pomeni, da vzamemo pot od gostitelja, na katerem bomo zagnali - in jo vzamemo kot obseg. In potem ga imenujemo ime: gostitelj. Ta celoten hostPath namestimo znotraj sklopa. V tem primeru v imenik /host.
Še enkrat bom ponovil. Podu smo rekli, naj pride do masterja, tam dobi hostNetwork in hostPID - in namesti celoten koren masterja znotraj tega sklopa.
Razumete, da v Debianu teče bash in ta bash teče pod korenom. To pomeni, da smo pravkar prejeli root na masterju, ne da bi imeli kakršne koli pravice v gruči Kubernetes.
Potem je celotna naloga, da greste v podimenik /host /etc/kubernetes/pki, če se ne motim, tam poberete vsa glavna potrdila gruče in v skladu s tem postanete skrbnik gruče.
Če pogledate na ta način, je to nekaj najnevarnejših pravic v paketih – ne glede na to, katere pravice ima uporabnik:
Če imam pravice za zagon poda v nekem imenskem prostoru gruče, potem ima ta pod privzeto te pravice. Lahko poganjam privilegirane pode in to so na splošno vse pravice, praktično root na vozlišču.
Moj najljubši je Root user. In Kubernetes ima to možnost Run As Non-Root. To je vrsta zaščite pred hekerjem. Ali veste, kaj je "moldavski virus"? Če ste nenadoma heker in pridete v mojo gručo Kubernetes, potem mi, ubogi skrbniki, vprašamo: »Prosim, navedite v svojih podih, s katerimi boste vdrli v mojo gručo, zaženite kot nekorenski. V nasprotnem primeru se bo zgodilo, da boste postopek zagnali v svojem podu pod korenom in me boste zelo enostavno vdrli. Prosim, zaščitite se pred seboj."
Obseg gostiteljske poti je po mojem mnenju najhitrejši način za pridobitev želenega rezultata iz gruče Kubernetes.
Toda kaj storiti z vsem tem?
Misel, ki bi se morala poroditi vsakemu normalnemu skrbniku, ki se sreča s Kubernetesom, je: »Ja, rekel sem ti, Kubernetes ne deluje. V njem so luknje. In celoten Cube je sranje.« Pravzaprav obstaja nekaj takega, kot je dokumentacija, in če pogledate tja, obstaja razdelek .
To je objekt yaml - ustvarimo ga lahko v gruči Kubernetes - ki nadzira varnostne vidike posebej v opisu podov. To pomeni, da dejansko nadzoruje pravice za uporabo katerega koli gostiteljskega omrežja, gostiteljskegaPID-ja, določenih vrst nosilcev, ki so v podih ob zagonu. S pomočjo varnostne politike Pod je vse to mogoče opisati.
Najbolj zanimiva stvar pri varnostni politiki Pod je, da v gruči Kubernetes vsi namestitveni programi PSP niso le opisani na noben način, ampak so preprosto privzeto onemogočeni. Varnostna politika Pod je omogočena z vtičnikom za sprejem.
V redu, razmestimo Pod Security Policy v gručo, recimo, da imamo nekaj storitvenih podov v imenskem prostoru, do katerih imajo dostop samo skrbniki. Recimo, v vseh drugih primerih imajo pods omejene pravice. Ker najverjetneje razvijalcem ni treba izvajati privilegiranih podov v vaši gruči.
In zdi se, da je pri nas vse v redu. In naše gruče Kubernetes ni mogoče vdreti v dveh minutah.
Tukaj je problem. Najverjetneje, če imate gručo Kubernetes, je nadzor nameščen v vaši gruči. Šel bi celo tako daleč, da bi napovedal, da če ima vaša gruča nadzor, se bo imenovala Prometej.
To, kar vam bom povedal, bo veljalo tako za operaterja Prometheus kot za Prometheus v čisti obliki. Vprašanje je, da če ne morem tako hitro spraviti skrbnika v gručo, to pomeni, da moram iskati več. In lahko iščem s pomočjo vašega spremljanja.
Verjetno vsi berejo iste članke na Habréju, spremljanje pa se nahaja v imenskem prostoru spremljanja. Shema krmila se imenuje približno enako za vse. Predvidevam, da boste, če helm namestite stable/prometheus, imeli približno enaka imena. In najverjetneje mi sploh ne bo treba ugibati imena DNS v vaši gruči. Ker je standardno.
Nato imamo določen razvijalec, v katerem lahko zaženete določen pod. In potem je iz tega sklopa zelo enostavno narediti nekaj takega:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics je eden od izvoznikov Prometheus, ki zbira metrike iz samega API-ja Kubernetes. Tam je veliko podatkov, kaj teče v vašem grozdu, kaj je, kakšne težave imate s tem.
Kot preprost primer:
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
Če naredite preprosto zahtevo za curl iz neprivilegiranega sklopa, lahko dobite naslednje informacije. Če ne veste, katero različico Kubernetesa uporabljate, vam bo zlahka povedala.
In najbolj zanimivo je to, da lahko poleg dostopa do kube-state-metrics prav tako preprosto neposredno dostopate do samega Prometheusa. Od tam lahko zbirate meritve. Od tam lahko celo sestavite meritve. Tudi teoretično lahko takšno poizvedbo zgradite iz gruče v Prometheusu, ki jo bo preprosto izklopila. Vaše spremljanje bo popolnoma prenehalo delovati iz gruče.
In tu se pojavi vprašanje, ali kakšen zunanji nadzor spremlja vaše spremljanje. Pravkar sem dobil priložnost delovati v gruči Kubernetes brez posledic zase. Sploh ne boste vedeli, da tam operiram, saj ni več nadzora.
Tako kot pri PSP se zdi, da je težava v tem, da vse te modne tehnologije - Kubernetes, Prometheus - preprosto ne delujejo in so polne lukenj. res ne.
Obstaja nekaj takega - .
Če ste običajen skrbnik, potem verjetno veste o omrežni politiki, da je to samo še en yaml, ki jih je že veliko v gruči. In nekatere omrežne politike zagotovo niso potrebne. In tudi če ste prebrali, kaj je omrežna politika, da je požarni zid yaml Kubernetesa, omogoča vam omejitev pravic dostopa med imenskimi prostori, med podi, potem ste se gotovo odločili, da požarni zid v formatu yaml v Kubernetesu temelji na naslednjih abstrakcijah ... Ne, ne . To vsekakor ni potrebno.
Tudi če svojim strokovnjakom za varnost niste povedali, da lahko s svojim Kubernetesom zgradite zelo enostaven in preprost požarni zid, in to zelo zrnat. Če tega še ne vedo in vas ne motijo: "No, daj mi, daj mi ..." Potem v vsakem primeru potrebujete omrežno politiko, da blokirate dostop do nekaterih servisnih mest, ki jih je mogoče potegniti iz vaše gruče brez kakršnega koli pooblastila.
Kot v primeru, ki sem ga dal, lahko metrike stanja kube povlečete iz katerega koli imenskega prostora v gruči Kubernetes, ne da bi za to imeli kakršne koli pravice. Omrežne politike so zaprle dostop iz vseh drugih imenskih prostorov do nadzornega imenskega prostora in to je to: ni dostopa, ni težav. V vseh grafikonih, ki obstajajo, tako v standardnem Prometheusu kot v Prometheusu, ki je v operaterju, je v krmilnih vrednostih preprosto možnost, da zanje preprosto omogočite omrežne politike. Samo vklopiti jih morate in delovale bodo.
Tukaj je res ena težava. Ker ste običajen bradati skrbnik, ste se najverjetneje odločili, da omrežni pravilniki niso potrebni. In po branju vseh vrst člankov o virih, kot je Habr, ste se odločili, da je flanel, zlasti z načinom gostiteljskega prehoda, najboljša stvar, ki jo lahko izberete.
Kaj storiti?
Lahko poskusite znova namestiti omrežno rešitev, ki jo imate v gruči Kubernetes, poskusite jo zamenjati z nečim bolj funkcionalnim. Za isti Calico, na primer. Vendar želim takoj povedati, da je naloga spreminjanja omrežne rešitve v delovni gruči Kubernetes precej netrivialna. Rešil sem ga dvakrat (obakrat sicer teoretično), vendar smo pri Slurmsu celo pokazali, kako se to naredi. Za naše študente smo pokazali, kako spremeniti omrežno rešitev v gruči Kubernetes. Načeloma lahko poskusite zagotoviti, da na proizvodnem grozdu ne pride do izpadov. Ampak verjetno vam ne bo uspelo.
In problem je pravzaprav rešen zelo preprosto. V gruči so potrdila in veste, da bodo vaša potrdila potekla čez eno leto. No, in običajno običajna rešitev s certifikati v gruči - zakaj nas skrbi, v bližini bomo postavili nov grozd, pustili starega gniti in vse prerazporedili. Res je, ko bo gnilo, bomo morali sedeti en dan, ampak tukaj je nova gruča.
Ko dvignete nov grozd, hkrati namesto flanele vstavite Calico.
Kaj storiti, če so vaši certifikati izdani za sto let in grozda ne boste prerazporedili? Obstaja nekaj takega, kot je Kube-RBAC-Proxy. To je zelo kul razvoj, omogoča vam, da se vgradite kot zabojnik stranske prikolice v kateri koli pod v gruči Kubernetes. In dejansko doda pooblastilo tej skupini prek RBAC samega Kubernetesa.
Obstaja en problem. Prej je bila ta rešitev Kube-RBAC-Proxy vgrajena v operaterjev Prometheus. Toda potem ga ni bilo več. Zdaj se sodobne različice zanašajo na dejstvo, da imate omrežno politiko in jo zaprete z njihovo uporabo. In zato bomo morali grafikon nekoliko prepisati. Pravzaprav, če greš na , obstajajo primeri, kako to uporabiti kot stranske prikolice, in karte bo treba minimalno prepisati.
Obstaja še ena majhna težava. Prometheus ni edini, ki deli svoje meritve vsakomur. Vse naše komponente gruče Kubernetes prav tako lahko vrnejo lastne meritve.
A kot sem že rekel, če ne morete dostopati do grozda in zbirati informacij, lahko naredite vsaj nekaj škode.
Zato bom na hitro pokazal dva načina, kako je mogoče uničiti gručo Kubernetes.
Nasmejal se boš, ko ti bom povedal, to sta dva resnična primera.
Prva metoda. Izčrpavanje virov.
Zaženimo še en poseben pod. Imel bo tak razdelek.
resources:
requests:
cpu: 4
memory: 4Gi Kot veste, so zahteve količina procesorja in pomnilnika, ki je na gostitelju rezerviran za določene sklope z zahtevami. Če imamo v gruči Kubernetes štirijedrnega gostitelja in tja prispejo štirje CPE podi z zahtevami, to pomeni, da do tega gostitelja ne bo mogel priti noben več podov z zahtevami.
Če zaženem tak pod, bom zagnal ukaz:
$ kubectl scale special-pod --replicas=...Potem nihče drug ne bo mogel namestiti v gručo Kubernetes. Ker bo vsem vozliščem zmanjkalo zahtev. In tako bom ustavil vašo gručo Kubernetes. Če to naredim zvečer, lahko ustavitve za precej dolgo časa.
Če ponovno pogledamo dokumentacijo Kubernetes, bomo videli to stvar, imenovano Limit Range. Nastavlja vire za objekte gruče. Objekt Limit Range lahko napišete v yaml, ga uporabite za določene imenske prostore – in nato v tem imenskem prostoru lahko rečete, da imate privzete, največje in najmanjše vire za pods.
S pomočjo take stvari lahko omejimo uporabnike v določenih imenskih prostorih izdelkov ekip pri zmožnosti označevanja vseh vrst zoprnih stvari na svojih podih. Toda na žalost, tudi če uporabniku poveste, da ne more zagnati podov z zahtevami za več kot en CPE, obstaja tako čudovit ukaz za merjenje ali pa lahko izvaja merilo prek nadzorne plošče.
In od tod izvira metoda številka dve. Lansiramo 11 strokov. To je enajst milijard. To ni zato, ker sem prišel do takšne številke, ampak zato, ker sem jo sam videl.
Resnična zgodba. Pozno zvečer sem se nameravala odpraviti iz pisarne. Vidim skupino razvijalcev, ki sedijo v kotu in mrzlično počnejo nekaj s svojimi prenosniki. Stopim do fantov in jih vprašam: "Kaj se vam je zgodilo?"
Malo prej, okrog devetih zvečer, se je eden od razvijalcev pripravljal domov. In odločil sem se: "Zdaj bom svojo aplikacijo zmanjšal na eno." Pritisnil sem eno, a je internet malo upočasnil. Spet je pritisnil eno, pritisnil je eno in kliknil Enter. Zbadal sem v vse, kar sem lahko. Potem je internet zaživel - in vse se je začelo zmanjševati na to številko.
Res je, ta zgodba se ni dogajala na Kubernetesu, takrat je bil to Nomad. Končalo se je tako, da je po eni uri naših poskusov, da bi Nomadu preprečili vztrajne poskuse skaliranja, Nomad odgovoril, da s skaliranjem ne bo prenehal in da ne bo naredil ničesar drugega. "Utrujen sem, odhajam." In se je zvil.
Seveda sem poskušal narediti enako na Kubernetesu. Kubernetes ni bil zadovoljen z enajstimi milijardami podov, rekel je: »Ne morem. Presega notranje ščitnike za usta." Toda 1 strokov bi lahko.
Kot odgovor na milijardo se Kocka ni umaknila vase. Res se je začel skaliti. Bolj kot je šel proces, več časa je potreboval, da je ustvaril nove stroke. Vendar se je proces vseeno nadaljeval. Edina težava je, da če lahko neomejeno zaganjam pode v svojem imenskem prostoru, potem lahko tudi brez zahtev in omejitev zaženem toliko podov z nekaterimi nalogami, da se bodo s pomočjo teh nalog vozlišča začela seštevati v pomnilniku, v CPU. Ko lansiram toliko podov, bi morale informacije iz njih iti v shrambo, to je itd. In ko tja prispe preveč informacij, se shramba začne vračati prepočasi – in Kubernetes začne postajati dolgočasen.
In še en problem ... Kot veste, krmilni elementi Kubernetes niso ena osrednja stvar, ampak več komponent. Zlasti obstaja upravitelj krmilnika, razporejevalnik itd. Vsi ti fantje bodo hkrati začeli opravljati nepotrebno, neumno delo, ki bo sčasoma začelo jemati vse več časa. Upravitelj krmilnika bo ustvaril nove sklope. Razporejevalnik bo poskušal najti novo vozlišče zanje. Najverjetneje vam bo kmalu zmanjkalo novih vozlišč v gruči. Grozd Kubernetes bo začel delovati vse počasneje.
Vendar sem se odločil iti še dlje. Kot veste, v Kubernetesu obstaja takšna stvar, imenovana storitev. No, privzeto v vaših gručih najverjetneje storitev deluje z uporabo tabel IP.
Če na primer zaženete eno milijardo podov in nato s skriptom prisilite Kubernetis, da ustvari nove storitve:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Na vseh vozliščih gruče bo vedno več novih pravil iptables ustvarjenih približno istočasno. Poleg tega bo za vsako storitev ustvarjena milijarda pravil iptables.
Vse to sem preveril na nekaj tisočih, do desetih. In problem je, da je že pri tem pragu precej problematično narediti ssh do vozlišča. Ker se paketi, ki gredo skozi toliko verig, ne počutijo preveč dobro.
In tudi to je vse rešeno s pomočjo Kubernetesa. Obstaja tak objekt kvote virov. Nastavi število razpoložljivih virov in objektov za imenski prostor v gruči. V vsakem imenskem prostoru gruče Kubernetes lahko ustvarimo objekt yaml. Z uporabo tega objekta lahko rečemo, da imamo za ta imenski prostor dodeljeno določeno število zahtev in omejitev, nato pa lahko rečemo, da je v tem imenskem prostoru mogoče ustvariti 10 storitev in 10 podov. In en sam razvijalec se lahko ob večerih vsaj zaduši. Kubernetes mu bo rekel: "Svojih podov ne moreš povečati na to količino, ker vir presega kvoto." To je to, problem rešen. .
V zvezi s tem se pojavi ena problematična točka. Čutite, kako težko postaja ustvarjanje imenskega prostora v Kubernetesu. Da ga ustvarimo, moramo upoštevati marsikaj.
Kvota virov + omejitev obsega + RBAC
• Ustvarite imenski prostor
• Znotraj ustvarite mejno območje
• Ustvarite notranjo kvoto virov
• Ustvarite servisni račun za CI
• Ustvarite povezovanje vlog za CI in uporabnike
• Po želji zaženite potrebne storitvene enote
Zato bi rad izkoristil to priložnost in delil svoj razvoj. Obstaja nekaj takega, ki se imenuje operater SDK. To je način, da gruča Kubernetes napiše operatorje zanjo. Izjave lahko pišete z uporabo Ansible.
Sprva je bilo napisano v Ansibleu, nato pa sem videl, da obstaja operater SDK, in vlogo Ansible prepisal v operaterja. Ta izjava vam omogoča, da v gruči Kubernetes ustvarite predmet, imenovan ukaz. Znotraj ukaza vam omogoča, da opišete okolje za ta ukaz v yamlu. In v timskem okolju nam omogoča, da opišemo, da dodeljujemo toliko virov.
Malo .
In za zaključek. Kaj storiti z vsem tem?
najprej Varnostna politika Pod je dobra. In kljub dejstvu, da jih nobeden od namestitvenih programov Kubernetes ne uporablja do danes, jih morate še vedno uporabljati v svojih gručih.
Omrežni pravilnik ni samo še ena nepotrebna funkcija. To je tisto, kar je res potrebno v grozdu.
LimitRange/ResourceQuota - čas je, da ga uporabite. To smo začeli uporabljati že dolgo nazaj in dolgo časa sem bil prepričan, da ga uporabljajo vsi. Izkazalo se je, da je to redko.
Poleg tega, kar sem omenil med poročilom, obstajajo nedokumentirane funkcije, ki vam omogočajo napad na gručo. Izdano pred kratkim .
Nekatere stvari so tako žalostne in boleče. Pod določenimi pogoji lahko na primer kocke v gruči Kubernetes posredujejo vsebino imenika Warlocks nepooblaščenemu uporabniku.
Obstajajo navodila, kako reproducirati vse, kar sem vam povedal. Obstajajo datoteke z produkcijskimi primeri, kako sta videti ResourceQuota in Pod Security Policy. In vsega tega se lahko dotaknete.
Hvala vsem.
Vir: www.habr.com