Pavel Selivanov, Southbridge rješenja arhitekt i Slurm učitelj, održao je prezentaciju na DevOpsConf 2019. Ovaj govor je dio jedne od tema dubinskog tečaja o Kubernetesu “Slurm Mega”.
održava se u Moskvi od 18. do 20. studenog.
— Moskva, 22.-24.XI.
uvijek dostupno.
Ispod reza nalazi se prijepis izvješća.
Dobar dan, kolege i oni koji suosjećaju s njima. Danas ću govoriti o sigurnosti.
Vidim da je danas u dvorani puno zaštitara. Unaprijed Vam se ispričavam ako izraze iz svijeta sigurnosti koristim ne baš onako kako je to kod Vas uobičajeno.
Slučajno sam prije otprilike šest mjeseci naišao na jedan javni Kubernetes klaster. Javno znači da postoji n-ti broj prostora imena; u tim prostorima imena postoje korisnici izolirani u svom prostoru imena. Svi ti korisnici pripadaju različitim tvrtkama. Pa, pretpostavljalo se da bi se ovaj klaster trebao koristiti kao CDN. Odnosno, oni vam daju klaster, oni vam tamo daju korisnika, vi odete tamo u svoj imenski prostor, rasporedite svoje frontove.
Moja prethodna tvrtka pokušala je prodati takvu uslugu. I zamoljen sam da probodem klaster da vidim je li ovo rješenje prikladno ili ne.
Došao sam do ovog klastera. Dobio sam ograničena prava, ograničeni prostor imena. Momci su tamo razumjeli što je sigurnost. Čitali su o kontroli pristupa temeljenoj na ulogama (RBAC) u Kubernetesu - i izokrenuli su je tako da nisam mogao pokrenuti module odvojeno od implementacija. Ne sjećam se problema koji sam pokušavao riješiti pokretanjem jedinice bez postavljanja, ali stvarno sam želio pokrenuti samo jedinicu. Za sreću sam odlučio vidjeti koja prava imam u klasteru, što smijem, što ne smijem i što su tamo zeznuli. U isto vrijeme, reći ću vam što su krivo konfigurirali u RBAC-u.
Dogodilo se da sam u dvije minute primio admina u njihov klaster, pogledao sve susjedne namespacee, vidio tamo pokrenute proizvodne fronte tvrtki koje su već kupile uslugu i implementirale. Jedva sam se suzdržao da ne odem ispred nekoga i stavim neku psovku na glavnu stranicu.
Reći ću vam na primjerima kako sam to učinio i kako se zaštititi od toga.
Ali prvo da se predstavim. Moje ime je Pavel Selivanov. Ja sam arhitekt u Southbridgeu. Razumijem Kubernetes, DevOps i sve vrste otmjenih stvari. Inženjeri Southbridgea i ja gradimo sve ovo, a ja se savjetujem.
Uz naše glavne aktivnosti, nedavno smo pokrenuli projekte pod nazivom Slurms. Pokušavamo našu sposobnost rada s Kubernetesom malo približiti masama, naučiti druge ljude da također rade s K8s.
O čemu ću danas pričati? Tema izvješća je očita – o sigurnosti Kubernetes klastera. Ali želim odmah reći da je ova tema vrlo velika - i stoga želim odmah razjasniti ono o čemu definitivno neću govoriti. Neću govoriti o otrcanim pojmovima koji su već stotinu puta korišteni na internetu. Sve vrste RBAC i certifikata.
Govorit ću o tome što mene i moje kolege boli u vezi sigurnosti u Kubernetes klasteru. Te probleme vidimo i među pružateljima koji pružaju Kubernetes klastere i među klijentima koji nam dolaze. Pa čak i od klijenata koji nam dolaze iz drugih konzultantskih administrativnih tvrtki. Odnosno, razmjeri tragedije zapravo su vrlo veliki.
Postoje doslovno tri točke o kojima ću danas govoriti:
- Korisnička prava naspram pod prava. Korisnička prava i pod prava nisu ista stvar.
- Prikupljanje informacija o klasteru. Pokazat ću da možete prikupiti sve informacije koje su vam potrebne iz klastera bez posebnih prava u ovom klasteru.
- DoS napad na klaster. Ako ne možemo prikupiti podatke, u svakom slučaju ćemo moći staviti klaster. Govorit ću o DoS napadima na kontrolne elemente klastera.
Još jedna generalna stvar koju ću spomenuti je ono na čemu sam sve ovo testirao, na čemu definitivno mogu reći da sve radi.
Kao osnovu uzimamo instalaciju Kubernetes klastera koristeći Kubespray. Ako netko ne zna, ovo je zapravo skup uloga za Ansible. Stalno ga koristimo u svom radu. Dobra stvar je što ga možete kotrljati bilo gdje - možete ga kotrljati na komade željeza ili negdje u oblak. Jedna metoda instalacije u principu funkcionira za sve.
U ovom klasteru ću imati Kubernetes v1.14.5. Cijeli Cube klaster, koji ćemo razmotriti, podijeljen je u prostore imena, svaki prostor imena pripada posebnom timu, a članovi tog tima imaju pristup svakom prostoru imena. Ne mogu ići u različite imenske prostore, samo u vlastite. Ali postoji određeni administratorski račun koji ima prava na cijeli klaster.
Obećao sam da ćemo prvo dobiti administratorska prava za klaster. Trebamo posebno pripremljenu mahunu koja će razbiti Kubernetes klaster. Sve što trebamo učiniti je primijeniti ga na Kubernetes klaster.
kubectl apply -f pod.yamlOva mahuna će stići do jednog od gospodara Kubernetes klastera. Nakon toga klaster će nam rado vratiti datoteku pod nazivom admin.conf. U Cubeu ova datoteka pohranjuje sve administratorske certifikate, a istovremeno konfigurira API klastera. Ovako je lako dobiti administratorski pristup, mislim, 98% Kubernetes klastera.
Ponavljam, ovaj pod je napravio jedan razvojni programer u vašem klasteru koji ima pristup implementaciji svojih prijedloga u jedan mali prostor imena, sve je stegnuto od strane RBAC-a. Nije imao nikakva prava. No ipak je potvrda vraćena.
A sada o posebno pripremljenoj mahuni. Pokrećemo ga na bilo kojoj slici. Uzmimo debian:jessie kao primjer.
Imamo ovo:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Što je tolerancija? Masteri u Kubernetes klasteru obično su označeni nečim što se zove taint. A bit ove “zaraze” je da kaže da se podovi ne mogu dodijeliti glavnim čvorovima. Ali nitko se ne trudi naznačiti u bilo kojoj mahuni da je tolerantna na "infekciju". Odjeljak Toleration samo kaže da ako neki čvor ima NoSchedule, onda je naš čvor tolerantan na takvu infekciju - i nema problema.
Nadalje, kažemo da naš podređeni nije samo tolerantan, već želi i posebno ciljati gospodara. Jer majstori imaju ono najukusnije što nam treba - sve certifikate. Stoga kažemo nodeSelector - i imamo standardnu oznaku na masterima, koja vam omogućuje da od svih čvorova u klasteru odaberete točno one čvorove koji su masteri.
S ove dvije sekcije sigurno će doći do majstora. I bit će mu dopušteno da tamo živi.
Ali nije nam dovoljan samo dolazak majstoru. Ovo nam neće dati ništa. Dakle, sljedeće imamo ove dvije stvari:
hostNetwork: true
hostPID: true Određujemo da će naš modul, koji pokrenemo, živjeti u prostoru imena kernela, u prostoru imena mreže iu prostoru imena PID-a. Nakon što se pod pokrene na masteru, moći će vidjeti sva stvarna, živa sučelja ovog čvora, slušati sav promet i vidjeti PID svih procesa.
Onda su u pitanju sitnice. Uzmi etcd i čitaj što hoćeš.
Najzanimljivija stvar je ova značajka Kubernetesa, koja je tamo prisutna prema zadanim postavkama.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host A njegova bit je da možemo reći u modulu koji pokrećemo, čak i bez prava na ovaj klaster, da želimo stvoriti volumen tipa hostPath. To znači uzeti put od glavnog računala na kojem ćemo se pokrenuti - i uzeti ga kao volumen. I onda to zovemo imenom: host. Cijeli ovaj hostPath montiramo unutar modula. U ovom primjeru, u direktorij /host.
Ponovit ću opet. Rekli smo modulu da dođe do mastera, tamo uzme hostNetwork i hostPID - i montira cijeli korijen mastera unutar ovog modula.
Razumijete da u Debianu imamo bash koji radi, a ovaj bash radi pod root-om. Odnosno, upravo smo dobili root na masteru, bez ikakvih prava u Kubernetes klasteru.
Zatim je cijeli zadatak otići u poddirektorij /host /etc/kubernetes/pki, ako se ne varam, tamo pokupiti sve glavne certifikate klastera i prema tome postati administrator klastera.
Ako na to gledate na ovaj način, ovo su neka od najopasnijih prava u podovima - bez obzira na to koja prava korisnik ima:
Ako imam prava pokrenuti pod u nekom prostoru imena klastera, onda ovaj pod ima ta prava prema zadanim postavkama. Mogu pokrenuti privilegirane podove, a to su općenito sva prava, praktički root na čvoru.
Moj favorit je Root user. I Kubernetes ima ovu opciju Run As Non-Root. Ovo je vrsta zaštite od hakera. Znate li što je "moldavski virus"? Ako ste odjednom haker i dođete na moj Kubernetes klaster, onda vas mi, jadni administratori, pitamo: „Molim vas, navedite u svojim podovima s kojim ćete hakirati moj klaster, pokrenuti kao non-root. U protivnom će se dogoditi da pokrenete proces u svom podu pod rootom i bit će vam vrlo lako hakirati me. Molimo zaštitite se od sebe."
Host path volume je, po mom mišljenju, najbrži način da dobijete željeni rezultat od Kubernetes klastera.
Ali što učiniti sa svim tim?
Misao koja bi trebala pasti na pamet svakom normalnom administratoru koji se susreće s Kubernetesom je: “Da, rekao sam ti, Kubernetes ne radi. U njemu su rupe. A cijeli Cube je sranje.” Zapravo, postoji nešto poput dokumentacije, a ako pogledate tamo, postoji odjeljak .
Ovo je yaml objekt - možemo ga stvoriti u Kubernetes klasteru - koji kontrolira sigurnosne aspekte posebno u opisu mahuna. To jest, zapravo, kontrolira prava za korištenje bilo koje hostNetwork, hostPID, određene vrste volumena koji se nalaze u podovima pri pokretanju. Uz pomoć Pod Security Policy sve se to može opisati.
Najzanimljivija stvar vezana uz Pod Security Policy je da u Kubernetes klasteru svi instalateri PSP-a ne samo da nisu ni na koji način opisani, već su jednostavno onemogućeni prema zadanim postavkama. Sigurnosna politika Poda omogućena je pomoću dodatka za pristup.
U redu, implementirajmo Pod Security Policy u klaster, recimo da imamo neke servisne podove u prostoru imena, kojima samo administratori imaju pristup. Recimo, u svim ostalim slučajevima mahune imaju ograničena prava. Budući da najvjerojatnije programeri ne moraju pokretati privilegirane module u vašem klasteru.
I čini se da je kod nas sve u redu. A naš Kubernetes klaster ne može se hakirati u dvije minute.
Imamo problem. Najvjerojatnije, ako imate Kubernetes klaster, tada je nadzor instaliran na vašem klasteru. Čak bih otišao tako daleko da predvidim da će se vaš klaster, ako ima nadzor, zvati Prometej.
Ono što ću vam reći vrijedit će i za Prometheus operatera i za Prometheus isporučen u svom čistom obliku. Pitanje je da ako ne mogu tako brzo dobiti administratora u klaster, onda to znači da moram više tražiti. I mogu tražiti uz pomoć vašeg praćenja.
Vjerojatno svi čitaju iste članke na Habréu, a monitoring se nalazi u imenskom prostoru monitoringa. Helm karta se zove otprilike isto za sve. Pretpostavljam da ćete, ako helm instalirate stable/prometheus, završiti s otprilike istim imenima. I najvjerojatnije neću morati čak ni pogađati DNS naziv u vašem klasteru. Zato što je standardno.
Zatim imamo određene programe u kojima možete pokrenuti određenu pod. A onda je iz ove mahune vrlo lako napraviti nešto poput ovoga:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics je jedan od Prometheus izvoznika koji prikuplja metriku iz samog Kubernetes API-ja. Tu ima puno podataka, što radi u vašem klasteru, što je to, kakve probleme imate s tim.
Kao jednostavan primjer:
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
Podnošenjem jednostavnog zahtjeva za curl iz neprivilegirane mahune, možete dobiti sljedeće informacije. Ako ne znate koju verziju Kubernetesa koristite, lako će vam reći.
A ono što je najzanimljivije je da osim pristupa kube-state-metrics-u, jednako tako jednostavno možete direktno pristupiti i samom Prometheusu. Odatle možete prikupljati mjerne podatke. Od tamo čak možete izgraditi metriku. Čak i teoretski, možete izgraditi takav upit iz klastera u Prometheusu, koji će ga jednostavno isključiti. I vaše praćenje će potpuno prestati raditi iz klastera.
I tu se postavlja pitanje prati li ikakav vanjski nadzor vaš nadzor. Upravo sam dobio priliku raditi u Kubernetes klasteru bez ikakvih posljedica za sebe. Nećete ni znati da tamo operiram jer više nema nadzora.
Baš kao i s PSP-om, čini se da je problem u tome što sve te otmjene tehnologije - Kubernetes, Prometheus - jednostavno ne rade i pune su rupa. Ne baš.
Postoji takva stvar - .
Ako ste normalan admin, onda vjerojatno znate za mrežnu politiku da je ovo samo još jedan yaml, kojih već ima puno u klasteru. A neka mrežna pravila definitivno nisu potrebna. Čak i ako ste pročitali što je mrežna politika, da je to yaml vatrozid Kubernetesa, omogućuje vam da ograničite prava pristupa između imenskih prostora, između podova, onda ste sigurno odlučili da se vatrozid u yaml formatu u Kubernetesu temelji na sljedećim apstrakcijama ... Ne, ne . Ovo definitivno nije potrebno.
Čak i ako niste rekli svojim stručnjacima za sigurnost da koristeći svoj Kubernetes možete izgraditi vrlo lak i jednostavan vatrozid, i to vrlo granularni. Ako oni to još ne znaju i ne gnjave vas: “Pa, daj mi, daj mi...” Onda u svakom slučaju trebate mrežnu politiku za blokiranje pristupa nekim servisnim mjestima koja se mogu povući iz vašeg klastera bez ikakvog ovlaštenja.
Kao u primjeru koji sam dao, možete povući kube metriku stanja iz bilo kojeg prostora imena u Kubernetes klasteru bez ikakvih prava za to. Mrežna pravila su zatvorila pristup iz svih drugih imenskih prostora nadzornom imenskom prostoru i to je to: nema pristupa, nema problema. U svim grafikonima koji postoje, i onom standardnom Prometheusu i onom Prometheusu koji je u operatoru, jednostavno postoji opcija u vrijednostima kormila da im se jednostavno omogući mrežna politika. Samo ih trebate uključiti i oni će raditi.
Ovdje zaista postoji jedan problem. Budući da ste obični bradati administrator, najvjerojatnije ste odlučili da mrežna pravila nisu potrebna. I nakon što ste pročitali sve vrste članaka o resursima kao što je Habr, odlučili ste da je flanel, posebno s host-gateway načinom, najbolja stvar koju možete odabrati.
Što učiniti?
Možete pokušati ponovno postaviti mrežno rješenje koje imate u svom Kubernetes klasteru, pokušati ga zamijeniti nečim funkcionalnijim. Za isti Calico, na primjer. Ali želim odmah reći da je zadatak promjene mrežnog rješenja u Kubernetes radnom klasteru prilično netrivijalan. Riješio sam ga dva puta (oba puta, doduše, teoretski), ali čak smo i pokazali kako se to radi na Slurmsu. Za naše studente pokazali smo kako promijeniti mrežno rješenje u Kubernetes klasteru. U principu, možete pokušati osigurati da nema zastoja u proizvodnom klasteru. Ali vjerojatno nećete uspjeti.
A problem se zapravo rješava vrlo jednostavno. U klasteru postoje certifikati, a znate da će vam certifikati isteći za godinu dana. Pa, i obično normalno rješenje s certifikatima u klasteru - zašto se brinemo, podići ćemo novi klaster u blizini, pustiti stari da se pokvari i sve preraspodijeliti. Istina, kad se pokvari, morat ćemo sjediti jedan dan, ali evo novog grozda.
Kada podižete novi grozd, u isto vrijeme umetnite Calico umjesto flanela.
Što učiniti ako su vam certifikati izdani na stotinu godina, a klaster ne namjeravate preraspodijeliti? Postoji nešto poput Kube-RBAC-Proxy. Ovo je vrlo cool razvoj, omogućuje vam da se ugradite kao kontejner s bočnom prikolicom u bilo koju pod u Kubernetes klasteru. I zapravo dodaje autorizaciju ovoj grupi putem RBAC-a samog Kubernetesa.
Postoji jedan problem. Prethodno je ovo Kube-RBAC-Proxy rješenje bilo ugrađeno u operaterov Prometheus. Ali onda je nestao. Sada se moderne verzije oslanjaju na činjenicu da imate mrežnu politiku i zatvarate je pomoću njih. I stoga ćemo morati malo prepisati grafikon. Zapravo, ako odete na , postoje primjeri kako to koristiti kao pomoćne prikolice, a karte će se morati minimalno prepisati.
Postoji još jedan mali problem. Prometheus nije jedini koji svoju metriku dijeli bilo kome. Sve naše komponente Kubernetes klastera također mogu vraćati vlastite metrike.
Ali kao što sam već rekao, ako ne možete pristupiti klasteru i prikupiti informacije, onda možete barem učiniti štetu.
Stoga ću brzo pokazati dva načina kako se Kubernetes klaster može uništiti.
Smijat ćete se kad vam ovo kažem, ovo su dva stvarna slučaja.
Metoda jedan. Iscrpljenost resursa.
Pustimo još jednu posebnu kapsulu. Imat će ovakav odjeljak.
resources:
requests:
cpu: 4
memory: 4Gi Kao što znate, zahtjevi su količina CPU-a i memorije koja je rezervirana na hostu za određene module sa zahtjevima. Ako imamo četverojezgreni host u Kubernetes klasteru i tamo stignu četiri CPU pod-a sa zahtjevima, to znači da više nijedan pod sa zahtjevima neće moći doći na ovaj host.
Ako pokrenem takav modul, tada ću pokrenuti naredbu:
$ kubectl scale special-pod --replicas=...Tada se nitko drugi neće moći implementirati u Kubernetes klaster. Jer će svi čvorovi ostati bez zahtjeva. I tako ću zaustaviti vaš Kubernetes klaster. Ako to učinim navečer, mogu zaustaviti raspoređivanje na prilično dugo vrijeme.
Ako ponovno pogledamo Kubernetes dokumentaciju, vidjet ćemo tu stvar koja se zove Limit Range. Postavlja resurse za objekte klastera. Objekt Limit Range možete napisati u yamlu, primijeniti ga na određene prostore imena - a zatim u tom prostoru imena možete reći da imate zadane, maksimalne i minimalne resurse za mahune.
Uz pomoć takve stvari, možemo ograničiti korisnike u određenim prostorima naziva proizvoda timova u mogućnosti da naznače svakakve gadne stvari na svojim podovima. Ali nažalost, čak i ako kažete korisniku da ne može pokrenuti module sa zahtjevima za više od jednog CPU-a, postoji tako divna naredba za skaliranje, ili mogu napraviti skaliranje putem nadzorne ploče.
I odatle dolazi metoda broj dva. Lansiramo 11 kapsula. To je jedanaest milijardi. To nije zato što sam došao do takvog broja, već zato što sam to sam vidio.
Prava priča. Kasno navečer sam se spremao izaći iz ureda. Vidim skupinu programera koji sjede u kutu i mahnito rade nešto sa svojim prijenosnim računalima. Priđem dečkima i pitam: "Što vam se dogodilo?"
Nešto ranije, oko devet navečer, jedan od programera spremao se kući. I odlučio sam: "Sad ću smanjiti svoju aplikaciju na jednu." Pritisnuo sam jednu, ali internet je malo usporio. Ponovno je pritisnuo onaj, pritisnuo je jedan i kliknuo Enter. Bockao sam sve što sam mogao. Onda je Internet zaživio - i sve se počelo smanjivati na ovaj broj.
Istina, ova se priča nije odvijala na Kubernetesu; tada je to bio Nomad. Završilo je tako što je nakon sat vremena naših pokušaja da spriječimo Nomada u upornim pokušajima skaliranja, Nomad odgovorio da neće prestati skalirati i da neće raditi ništa drugo. – Umoran sam, odlazim. I sklupčao se.
Naravno, pokušao sam učiniti isto na Kubernetesu. Kubernetes nije bio zadovoljan s jedanaest milijardi mahuna, rekao je: “Ne mogu. Premašuje unutarnje štitnike za usta." Ali 1 mahuna bi moglo.
Kao odgovor na milijardu, Kocka se nije povukla u sebe. Stvarno je počeo skalirati. Što je proces išao dalje, to mu je više vremena trebalo da stvori nove mahune. Ali proces je ipak tekao. Jedini je problem što ako mogu neograničeno pokretati podove u svom imenskom prostoru, onda čak i bez zahtjeva i ograničenja mogu pokrenuti toliko podova s nekim zadacima da će se uz pomoć tih zadataka čvorovi početi zbrajati u memoriji, u CPU-u. Kad lansiram toliko podova, informacije iz njih trebale bi ići u pohranu, to jest itd. A kada tamo stigne previše informacija, pohrana se počinje presporo vraćati – i Kubernetes počinje dosaditi.
I još jedan problem... Kao što znate, kontrolni elementi Kubernetesa nisu jedna središnja stvar, već nekoliko komponenti. Konkretno, postoji upravitelj kontrolera, planer i tako dalje. Svi ti dečki počet će istovremeno raditi nepotrebne, glupe poslove, koji će s vremenom početi oduzimati sve više vremena. Upravitelj kontrolera izradit će nove mahune. Planer će pokušati pronaći novi čvor za njih. Najvjerojatnije će vam uskoro ponestati novih čvorova u vašem klasteru. Kubernetes klaster će početi raditi sve sporije.
Ali odlučio sam ići još dalje. Kao što znate, u Kubernetesu postoji nešto što se zove usluga. Pa, prema zadanim postavkama u vašim klasterima, najvjerojatnije, usluga radi pomoću IP tablica.
Ako, na primjer, pokrenete milijardu podova, a zatim pomoću skripte prisilite Kubernetis da stvori nove usluge:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Na svim čvorovima klastera sve će se više i više novih iptables pravila generirati približno istovremeno. Štoviše, jedna milijarda iptables pravila bit će generirana za svaku uslugu.
Provjerio sam cijelu ovu stvar na nekoliko tisuća, do deset. A problem je što je već na ovom pragu prilično problematično napraviti ssh čvoru. Zato što paketi, koji prolaze kroz toliko lanaca, počinju biti lošiji.
I to je također sve riješeno uz pomoć Kubernetesa. Postoji takav objekt kvote resursa. Postavlja broj dostupnih resursa i objekata za imenski prostor u klasteru. Možemo stvoriti yaml objekt u svakom prostoru imena Kubernetes klastera. Koristeći ovaj objekt, možemo reći da imamo određeni broj zahtjeva i ograničenja dodijeljenih za ovaj prostor imena, a zatim možemo reći da je u ovom prostoru imena moguće kreirati 10 usluga i 10 podova. A jedan programer može se barem navečer ugušiti. Kubernetes će mu reći: "Ne možete skalirati svoje mahune na tu količinu, jer resurs premašuje kvotu." To je to, problem riješen. .
U vezi s tim javlja se jedna problematična točka. Osjećate kako postaje teško stvoriti imenski prostor u Kubernetesu. Da bismo ga stvorili, moramo uzeti u obzir puno stvari.
Kvota resursa + Raspon ograničenja + RBAC
• Stvorite imenski prostor
• Stvorite ograničenje unutar
• Stvorite unutarnju kvotu resursa
• Napravite servisni račun za CI
• Stvorite rolebinding za CI i korisnike
• Po želji pokrenite potrebne servisne module
Stoga bih želio iskoristiti ovu priliku da podijelim svoj razvoj. Postoji takva stvar koja se zove SDK operator. Ovo je način na koji Kubernetes klaster može napisati operatore za sebe. Možete pisati izjave koristeći Ansible.
Prvo je bilo napisano u Ansibleu, a onda sam vidio da postoji SDK operator i prepisao Ansible ulogu u operator. Ova izjava vam omogućuje stvaranje objekta u Kubernetes klasteru koji se zove naredba. Unutar naredbe omogućuje vam da opišete okruženje za ovu naredbu u yamlu. A unutar timskog okruženja, to nam omogućuje da opišemo da dodjeljujemo toliko resursa.
Mala .
I zaključno. Što učiniti sa svim ovim?
Prvi. Politika sigurnosti pod je dobra. I unatoč činjenici da ih niti jedan Kubernetes instalater ne koristi do danas, još uvijek ih morate koristiti u svojim klasterima.
Mrežna politika nije samo još jedna nepotrebna značajka. To je ono što je stvarno potrebno u klasteru.
LimitRange/ResourceQuota - vrijeme je za korištenje. Ovo smo počeli koristiti davno i dugo sam bio siguran da ga svi koriste. Pokazalo se da je to rijetkost.
Uz ono što sam spomenuo tijekom izvješća, postoje nedokumentirane značajke koje vam omogućuju napad na klaster. Nedavno objavljeno .
Neke stvari su tako tužne i bolne. Na primjer, pod određenim uvjetima, kocke u Kubernetes klasteru mogu dati sadržaj direktorija warlocks neovlaštenom korisniku.
Postoje upute kako reproducirati sve što sam vam rekao. Postoje datoteke s proizvodnim primjerima kako izgledaju ResourceQuota i Pod Security Policy. I sve ovo možete dotaknuti.
Hvala svima.
Izvor: www.habr.com