Pavel Selivanov, arhitekta Southbridge rješenja i Slurm učitelj, održao je predavanje na DevOpsConf 2019. Ovaj govor je dio jedne od tema Slurm Mega naprednog Kubernetes kursa.
održava se u Moskvi od 18. do 20. novembra.
- Moskva, 22-24. novembar.
uvijek na raspolaganju.
Ispod presjeka - transkript izvještaja.
Dobar dan, kolege i simpatizeri. Danas ću govoriti o sigurnosti.
Vidim da je danas dosta ljudi iz obezbjeđenja u sali. Unaprijed vam se izvinjavam ako koristim pojmove iz svijeta sigurnosti ne baš onako kako vi to inače koristite.
Desilo se da mi je prije otprilike šest mjeseci jedan javni Kubernetes klaster pao u ruke. Javno - znači da postoji n-ti broj imenskih prostora, u tim imenskim prostorima postoje korisnici izolirani u njihovom imenskom prostoru. Svi ovi korisnici pripadaju različitim kompanijama. Pa, pretpostavljalo se da ovaj klaster treba da se koristi kao CDN. Odnosno, daju vam klaster, daju korisnika tamo, odete tamo u svoj prostor imena, rasporedite svoje frontove.
Moja prethodna kompanija pokušala je prodati takvu uslugu. I zamolili su me da probodem klaster na temu – da li je takvo rješenje prikladno ili ne.
Došao sam u ovaj klaster. Dobio sam ograničena prava, ograničen imenski prostor. Tu su momci shvatili šta je obezbeđenje. Pročitali su šta je kontrola pristupa zasnovana na ulogama (RBAC) u Kubernetesu - i izvrnuli su je tako da ne mogu da pokrećem podove odvojeno od implementacija. Ne sjećam se problema koji sam pokušavao riješiti pokretanjem pod-a bez implementacije, ali sam stvarno želio pokrenuti samo pod. Odlučio sam na sreću da vidim koja prava imam u klasteru, šta mogu, šta ne mogu, šta su tu zeznuli. Istovremeno ću vam reći šta su pogrešno konfigurisali u RBAC-u.
Dogodilo se da sam za dva minuta dobio admina za njihov klaster, pogledao sve susjedne namespacee, vidio frontove proizvodnje kompanija koje su već kupile uslugu i tamo postavile. Jedva sam se zaustavio da ne dođem do nekog ispred i stavim koju psovku na glavnu stranicu.
Reći ću vam na primjerima kako sam to radio i kako se od toga odbraniti.
Ali prvo, dozvolite mi da se predstavim. Moje ime je Pavel Selivanov. Ja sam arhitekta za Southbridge. Razumijem Kubernetes, DevOps i sve vrste otmjenih stvari. Inženjeri Southbridgea i ja sve to gradimo, a ja se konsultujem.
Uz naše glavne aktivnosti, nedavno smo pokrenuli projekte pod nazivom Slurms. Pokušavamo da svoju sposobnost rada sa Kubernetesom malo približimo masama, da naučimo i druge ljude kako da rade sa K8s.
O čemu ću danas. Tema izvještaja je očigledna - o sigurnosti Kubernetes klastera. Ali odmah želim da kažem da je ova tema veoma velika - i zato želim odmah da preciziram o čemu definitivno neću govoriti. Neću da pričam o izluđenim terminima koji su već sto puta preterano upotrebljeni na internetu. Bilo koji RBAC i sertifikati.
Pričaću o tome šta boli mene i moje kolege iz bezbednosti u Kubernetes klasteru. Ove probleme vidimo i kod provajdera koji pružaju Kubernetes klastere i kod klijenata koji nam dolaze. Pa čak i za klijente koji nam dolaze iz drugih konsultantskih administrativnih kompanija. Odnosno, razmere tragedije su u stvari veoma velike.
Bukvalno tri tač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 prikupimo informacije, u svakom slučaju ćemo moći staviti klaster. Govoriću o DoS napadima na elemente kontrole klastera.
Još jedna generalna stvar koju ću spomenuti je na čemu sam sve to testirao, na čemu sa sigurnošću mogu reći da sve funkcionira.
Kao osnovu uzimamo instalaciju Kubernetes klastera koristeći Kubespray. Ako neko ne zna, ovo je zapravo skup uloga za Ansible. Koristimo ga stalno na poslu. Dobra stvar je što se možete kotrljati bilo gdje - i možete se kotrljati po komadima željeza, i negdje u oblaku. Jedna metoda ugradnje je u principu prikladna za sve.
U ovom klasteru ću imati Kubernetes v1.14.5. Cijeli klaster Cube, koji ćemo razmotriti, podijeljen je na prostore imena, svaki imenski prostor pripada zasebnom timu, članovi ovog tima imaju pristup svakom imenskom prostoru. Ne mogu ići u različite imenske prostore, samo u svoje. Ali postoji određeni administratorski račun koji ima prava na cijeli klaster.
Obećao sam da ćemo prvo dobiti administratorska prava na klaster. Potreban nam je posebno pripremljen pod koji će razbiti Kubernetes klaster. Sve što treba da uradimo je da ga primenimo na Kubernetes klaster.
kubectl apply -f pod.yamlOvaj pod će doći jednom od gospodara Kubernetes klastera. A klaster će rado vratiti datoteku pod nazivom admin.conf nakon toga. Na Kubi, ova datoteka pohranjuje sve administratorske certifikate, a istovremeno je konfiguriran API klastera. Mislim da je ovako lako dobiti administratorski pristup za 98% Kubernetes klastera.
Opet, ovaj pod je napravio jedan programer u vašem klasteru, koji ima pristup da implementira svoje prijedloge u jedan mali prostor imena, a sve ga drži RBAC. Nije imao nikakva prava. No, certifikat se ipak vratio.
A sada o posebno pripremljenom ognjištu. Pokrećemo na bilo kojoj slici. Uzmimo debian:jessie kao primjer.
imamo nešto ovako:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Šta je tolerancija? Masters u Kubernetes klasteru obično se označavaju nečim što se zove taint. A suština ove "infekcije" je da kaže da se podovi ne mogu dodijeliti glavnim čvorovima. Ali niko se ne trudi da u bilo kojoj kapsuli naznači da je tolerantan na “infekciju”. Odjeljak Toleracija samo kaže da ako je NoSchedule instaliran na nekom čvoru, onda je naš pod tolerantan na takvu infekciju - i nema problema.
Dalje, kažemo da je naša mahuna ne samo tolerantna, već želi i namjerno da udari gospodara. Jer majstori imaju najukusnije što nam treba - sve certifikate. Stoga kažemo nodeSelector - i imamo standardnu oznaku na masterima, koja vam omogućava da od svih čvorova klastera odaberete upravo one čvorove koji su master.
Sa ova dva dijela sigurno će doći do majstora. I biće mu dozvoljeno da tamo živi.
Ali samo dolazak kod majstora nije nam dovoljan. Neće nam ništa dati. Dakle, sljedeće imamo ove dvije stvari:
hostNetwork: true
hostPID: true Navodimo da će naš pod koji pokrećemo živjeti u imenskom prostoru kernela, mrežnom imenskom prostoru i PID imenskom prostoru. Kada se pod pokrene na masteru, moći će vidjeti sva stvarna, živa sučelja tog čvora, slušati sav promet i vidjeti PID-ove svih procesa.
Onda je do malih stvari. Uzmi etcd i čitaj šta želiš.
Najzanimljivija stvar je ova Kubernetes funkcija, koja je tu podrazumevano.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host A njegova suština je da možemo, u podu koji pokrećemo, čak i bez prava na ovaj klaster, reći da želimo da kreiramo volumen tipa hostPath. Dakle, uzmite stazu od hosta na kojoj ćemo krenuti - i uzmite to kao volumen. I onda ga zovemo imenom: host. Montiramo sav ovaj hostPath unutar pod. U ovom primjeru, u /host direktorij.
Još jednom ću ponoviti. Rekli smo pod-u da dođe do master-a, nabavi hostNetwork i hostPID tamo - i montira cijeli root master unutar ovog pod-a.
Shvaćate da u debianu imamo bash pokrenut, a ovaj bash radi za nas kao root. Odnosno, upravo smo dobili root na master, a da nemamo nikakva prava u Kubernetes klasteru.
Tada je cijeli zadatak otići u direktorij / host / etc / kubernetes / pki, ako se ne varam, tamo pokupiti sve master certifikate klastera i, u skladu s tim, postati administrator klastera.
Ovako gledano, ovo su neka od najopasnijih prava u podovima, bez obzira koja prava korisnik ima:
Ako imam prava da pokrenem pod u nekom imenskom prostoru klastera, onda ovaj pod ima ta prava po defaultu. Mogu pokrenuti privilegovane podove, što je generalno sva prava, praktički root-ovanje čvora.
Moj favorit je Root korisnik. I Kubernetes ima ovu opciju Run As Non-Root. Ovo je vrsta zaštite od hakera. Znate li šta je „moldavski virus“? Ako ste odjednom haker i došli ste u moj Kubernetes klaster, onda vas mi, jadni administratori, pitamo: „Molim vas naznačite u svojim podovima sa kojima ćete hakovati moj klaster, pokrenuti kao non-root. U suprotnom, ispostaviće se da proces pokrećete u svom pod-u ispod root-a, i biće vam vrlo lako da me hakujete. Zaštitite se, molim vas."
Volumen putanje hosta - po mom mišljenju, najbrži način da dobijete željeni rezultat iz Kubernetes klastera.
Ali šta sa svim ovim?
Misli koje bi trebalo da padnu svakom normalnom administratoru koji naiđe na Kubernetes: „Da, rekao sam ti, Kubernetes ne radi. Ima rupe u sebi. A cijela Kocka je sranje.” U stvari, postoji takva stvar kao što je dokumentacija, i ako pogledate tamo, onda postoji dio .
Ovo je takav yaml objekat – možemo ga kreirati u Kubernetes klasteru – koji kontroliše bezbednosne aspekte u opisu podova. To jest, u stvari, kontrolira prava korištenja bilo koje hostNetwork, hostPID-a, određenih tipova volumena koji se nalaze u podovima pri pokretanju. Uz pomoć Pod Security Policy, sve se to može opisati.
Najzanimljivija stvar u vezi Pod Security Policy je da u Kubernetes klasteru svi instalateri PSP-a nisu samo ni na koji način opisani, već su jednostavno isključeni po defaultu. Pod Sigurnosna politika je omogućena pomoću dodatka za prijem.
U redu, hajde da implementiramo Pod Security Policy na klaster, recimo da imamo neke servisne podove u imenskom prostoru, kojima samo administratori imaju pristup. Recimo, u svemu ostalom, mahune imaju ograničena prava. Jer najvjerovatnije programeri ne moraju pokretati privilegirane podove na vašem klasteru.
I izgleda da smo dobro. A naš Kubernetes klaster se ne može hakovati za dva minuta.
Postoji problem. Najvjerovatnije, ako imate Kubernetes klaster, onda je nadzor instaliran u vašem klasteru. Čak se obavezujem da predvidim da ako vaš klaster ima nadzor, onda se zove Prometej.
Ovo što ću vam sada reći će važiti i za Prometheus operator i za Prometheus isporučen u svom čistom obliku. Pitanje je, ako ne mogu tako brzo da dovedem administratora do klastera, onda to znači da moram više da tražim. I mogu pretraživati koristeći vaš nadzor.
Vjerovatno su svi čitali iste članke na Habréu, a nadzor se nalazi u nadzornom imenskom prostoru. Helm chart se zove približno isto za sve. Pretpostavljam da ako uradite helm install stable/prometheus trebalo bi da završite sa otprilike istim imenima. Čak i najvjerovatnije neću morati da pogađam DNS ime u vašem klasteru. Jer je standardno.
Zatim, imamo određene programere u kojima možete pokrenuti određeni pod. A onda je iz ove mahune vrlo lako uraditi ovako:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics je jedan od prometheus izvoznika koji prikuplja metriku iz samog Kubernetes API-ja. Tamo ima puno podataka, šta radi u vašem klasteru, šta je to, kakve probleme imate sa 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-apserver: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 uvijanje od neprivilegovanog pod, možete dobiti informacije poput ove. Ako ne znate koju verziju Kubernetesa koristite, lako će vam reći.
A najzanimljivije je da pored činjenice da pristupate kube-state-metrics, možete direktno pristupiti samom Prometheusu. Odatle možete prikupljati metriku. Odatle možete čak i izgraditi metriku. Čak i teoretski, možete napraviti takav upit iz klastera u Prometheusu, koji će ga jednostavno isključiti. I vaš nadzor će općenito prestati raditi iz klastera.
I tu se već postavlja pitanje da li bilo koji vanjski nadzor prati vaše praćenje. Upravo sam dobio priliku da radim u Kubernetes klasteru bez ikakvih posljedica po sebe. Nećete ni znati da ja tamo radim, pošto nadzor više ne postoji.
Baš kao i sa PSP-om, čini se da je problem u tome što sve ove fensi tehnologije - Kubernetes, Prometheus - jednostavno ne rade i pune su rupa. Ne baš.
Postoji tako nešto - .
Ako ste normalni admin, onda najvjerovatnije znate za Network Policy da je ovo još jedan yaml, od kojih već postoje dofiga u klasteru. A mrežne politike definitivno nisu potrebne. Čak i ako pročitate šta je mrežna politika, šta je Kubernetes yaml firewall, dozvoljava vam da ograničite prava pristupa između prostora imena, između podova, onda ste definitivno odlučili da je yaml firewall u Kubernetesu zasnovan na sledećim apstrakcijama... Ne -ne . Definitivno nije potrebno.
Čak i ako vašim stručnjacima za sigurnost to nije rečeno uz pomoć vašeg Kubernetesa, možete izgraditi vrlo lak i jednostavan firewall, i vrlo detaljan. Ako to još ne znaju i ne povuku vas: “Pa, daj, daj...” Onda vam je u svakom slučaju potrebna mrežna politika da blokirate pristup nekim servisnim mjestima koja možete povući iz svog klastera bez ikakvog ovlašćenja.
Kao u primjeru koji sam dao, možete povući metriku stanja kubea iz bilo kojeg imenskog prostora u Kubernetes klasteru bez ikakvih prava za to. Mrežne politike su zatvorile pristup iz svih ostalih imenskih prostora nadzornom imenskom prostoru i, takoreći, svemu: nema pristupa, nema problema. U svim grafikonima koji postoje, i standardnim prometheusom i prometheusom koji je u operatoru, jednostavno postoji opcija u vrijednostima kormila da jednostavno omogućite mrežne politike za njih. Samo ga trebate uključiti i oni će raditi.
Ovdje zaista postoji jedan problem. Budući da ste običan bradati administrator, najvjerovatnije ste odlučili da mrežna pravila nisu potrebna. I nakon što ste pročitali razne članke o resursima kao što je Habr, odlučili ste da je flanel, posebno s host-gateway modom, najbolja stvar koju možete odabrati.
Što da radim?
Možete pokušati ponovo rasporediti mrežno rješenje koje imate u svom Kubernetes klasteru, pokušajte ga zamijeniti nečim funkcionalnijim. Na istom Calico, na primjer. Ali odmah želim reći da je zadatak promjene mrežnog rješenja u radnom Kubernetes klasteru prilično netrivijalan. Rešio sam to dva puta (oba puta, međutim, teoretski), ali smo čak pokazali kako se to radi u Slurmsu. Našim studentima smo pokazali kako promijeniti mrežno rješenje u Kubernetes klasteru. U principu, možete pokušati osigurati da nema zastoja na proizvodnom klasteru. Ali vjerovatno nećete uspjeti.
A problem je zapravo riješen vrlo jednostavno. U klasteru postoje sertifikati, a znate da će vam se sertifikati pokvariti za godinu dana. Pa i obicno normalno resenje sa sertifikatima u klasteru - zasto cemo da se kupamo, podignemo novi klaster pored njega, pustimo ga da truli u starom, i sve prerasporedimo. Istina, kad istrune, sve će ležati jedan dan, ali onda nova grozd.
Kada podignete novi grozd, u isto vrijeme ubacite Calico umjesto flanela.
Šta učiniti ako imate certifikate izdate na sto godina, a ne namjeravate ponovo rasporediti klaster? Postoji takva stvar Kube-RBAC-Proxy. Ovo je vrlo cool razvoj, omogućava vam da se ugradite kao bočni kontejner u bilo koji pod u Kubernetes klasteru. I zapravo dodaje autorizaciju kroz RBAC samog Kubernetesa ovom pod-u.
Postoji jedan problem. Ranije je ovo Kube-RBAC-Proxy rješenje ugrađeno u prometej operatera. Ali onda je otišao. Sada se moderne verzije oslanjaju na činjenicu da imate mrežne politike i zatvorite ih s njima. I zato morate malo prepisati grafikon. U stvari, ako odete na , postoje primjeri kako ga koristiti kao pomoćne prikolice, a karte će se morati minimalno prepisati.
Postoji još jedan mali problem. Ne samo da Prometej nikome daje svoje metrike. U našem slučaju, sve komponente Kubernetes klastera također mogu dati svoje metrike.
Ali kao što sam rekao, ako ne možete pristupiti klasteru i prikupiti informacije, onda možete barem naštetiti.
Tako da ću vam brzo pokazati dva načina na koja se Kubernetes klaster može razboljeti.
Nasmejaćete se kada vam kažem, ovo su dva slučaja iz stvarnog života.
Prvi metod. Iscrpljenost resursa.
Lansiramo još jednu posebnu kapsulu. Imat će ovaj 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 podove zahtjeva. Ako imamo četverojezgreni host u Kubernetes klasteru, a četiri CPU pod-a stignu tamo sa zahtjevima, onda više podova sa zahtjevima ne može doći na ovaj host.
Ako pokrenem takav pod, onda izdajem naredbu:
$ kubectl scale special-pod --replicas=...Tada niko drugi neće moći da se implementira u Kubernetes klaster. Zato što će svi čvorovi ostati bez zahtjeva. I tako ću zaustaviti vaš Kubernetes klaster. Ako ovo uradim uveče, onda se raspoređivanje može zaustaviti na dosta dugo vremena.
Ako ponovo pogledamo Kubernetes dokumentaciju, vidjet ćemo nešto što se zove Limit Range. On postavlja resurse za objekte klastera. Možete napisati Limit Range objekt u yaml-u, primijeniti ga na određene prostore imena - i dalje u ovom imenskom prostoru možete reći da imate resurse za zadane, maksimalne i minimalne podove.
Uz pomoć takve stvari, možemo ograničiti korisnike u specifičnim timskim imenskim prostorima proizvoda od mogućnosti da naznače sve vrste gadnih stvari na njihovim podovima. Ali nažalost, čak i ako kažete korisniku da ne možete pokrenuti podove sa zahtjevima za više od jednog CPU-a, postoji tako divna naredba scale, pa, ili preko kontrolne ploče oni mogu izvršiti skaliranje.
I tu dolazi broj dva. Trčanje 11 111 111 111 111 pod. To je jedanaest milijardi. To nije zato što sam ja smislio takav broj, već zato što sam ga sam vidio.
Prava priča. Kasno uveče sam se spremao da napustim kancelariju. Gledam, grupa programera sjedi u ćošku i mahnito radi nešto s laptopima. Priđem momcima i pitam: "Šta ti se desilo?"
Nešto ranije, u devet sati uveče, jedan od programera je išao kući. I odlučio sam: „Sada ću povećati svoju aplikaciju na jedan.” Pritisnuo sam jednu i internet je postao malo dosadan. Opet je pritisnuo jednu, pritisnuo je jednu, pritisnuo Enter. Probao je sve što je mogao. Onda je internet zaživeo - i sve je počelo da se širi do danas.
Istina, ova priča se nije odigrala na Kubernetesu, u to vrijeme je to bio Nomad. Završilo se time da je nakon sat vremena naših pokušaja da zaustavimo Nomada od tvrdoglavih pokušaja skaliranja, Nomad je odgovorio da neće prestati s skaliranjem i da neće raditi ništa drugo. "Umoran sam, odlazim." I okrenuo se.
Naravno, pokušao sam da uradim isto na Kubernetesu. Jedanaest milijardi kapsula Kubernetesa nije zadovoljilo, rekao je: „Ne mogu. Premašuje interna ograničenja. Ali 1 mahuna bi moglo.
Kao odgovor na milijardu, Kocka se nije povukla u sebe. Zaista je počeo da raste. Što je proces dalje išao, više je vremena bilo potrebno za stvaranje novih podova. Ali proces se ipak nastavio. Jedini problem je što ako mogu pokrenuti podove u svom imenskom prostoru neograničeno, onda čak i bez zahtjeva i ograničenja, mogu pokrenuti toliki broj podova sa nekim zadacima da će uz pomoć ovih zadataka čvorovi početi da se zbrajaju iz memorije, na CPU. Kada pokrenem toliko podova, informacije iz njih moraju ući u skladište, tj. itd. A kada dođe previše informacija, skladište počinje da se vraća presporo - i Kubernetes počinje da postaje tup.
I još jedan problem... Kao što znate, Kubernetes kontrole nisu neka centralna stvar, već nekoliko komponenti. Tamo, posebno, postoji menadžer kontrolera, planer i tako dalje. Svi ovi momci će istovremeno početi da rade nepotrebne glupe poslove, za koje će vremenom početi da oduzimaju sve više vremena. Upravitelj kontrolera će kreirati nove podove. Planer će pokušati pronaći novi čvor za njih. Novi čvorovi u vašem klasteru će najvjerovatnije uskoro nestati. Kubernetes klaster će početi da radi sve sporije i sporije.
Ali odlučio sam da idem još dalje. Kao što znate, Kubernetes ima stvar koja se zove servis. Pa, prema zadanim postavkama u vašim klasterima, najvjerovatnije, usluga radi koristeći IP tablice.
Ako pokrenete milijardu podova, na primjer, a zatim koristite skriptu da prisilite Kubernetis da kreira 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 više i više novih iptables pravila će se generisati približno istovremeno. Štaviše, milijardu iptables pravila će biti generisano za svaku uslugu.
Provjerio sam cijelu ovu stvar na nekoliko hiljada, do desetina. A problem je što je već na ovom pragu prilično problematično napraviti ssh do čvora. Zato što paketi, prolazeći kroz toliko lanaca, počinju da se osećaju ne baš dobro.
I to je također sve riješeno uz pomoć Kubernetesa. Postoji takav objekat kvota resursa. Postavlja broj dostupnih resursa i objekata za imenski prostor u klasteru. Možemo kreirati yaml objekat u svakom imenskom prostoru Kubernetes klastera. Uz pomoć ovog objekta možemo reći da imamo određeni broj zahtjeva, ograničenja dodijeljena za ovaj imenski prostor, a dalje možemo reći da je moguće kreirati 10 servisa i 10 podova u ovom imenskom prostoru. A jedan programer može čak i sam sebe zgnječiti u večernjim satima. Kubernetes će mu reći: "Ne možete skalirati svoje podove na toliku količinu, jer ona premašuje kvotu resursa." To je to, problem rešen. .
U vezi s tim nastaje jedan problem. Osjećate koliko je teško stvoriti prostor imena u Kubernetesu. Da bismo ga kreirali, moramo uzeti u obzir gomilu stvari.
Kvota resursa + granični raspon + RBAC
• Kreirajte imenski prostor
• Kreirajte unutar graničnog opsega
• Kreirajte unutarnju kvotu resursa
• Kreirajte servisni nalog za CI
• Kreirajte povezivanje uloga za CI i korisnike
• Po želji pokrenite potrebne servisne module
Stoga, koristeći ovu priliku, želio bih podijeliti svoja dostignuća. Postoji takva stvar koja se zove SDK operator. Ovo je način na koji se u Kubernetes klasteru pišu izjave za njega. Možete pisati izjave sa Ansibleom.
Prvo smo pisali u Ansibleu, a onda sam pogledao šta je SDK operator i prepisao Ansible ulogu u operator. Ova izjava vam omogućava da kreirate objekat u Kubernetes klasteru koji se zove komanda. Unutar komande, omogućava vam da u yaml opišete okruženje za ovu naredbu. A unutar timskog okruženja, to nam omogućava da opišemo da dodjeljujemo toliko resursa.
Malo .
I u zaključku. Šta sa svim ovim?
Prvo. Pod Sigurnosna politika je dobra. I uprkos činjenici da ih nijedan od instalatera Kubernetesa ne koristi do danas, i dalje ih morate koristiti u svojim klasterima.
Mrežna politika nije neka druga nepotrebna funkcija. To je ono što je zaista potrebno u klasteru.
LimitRange / ResourceQuota - vrijeme je za korištenje. Počeli smo da ga koristimo davno, i dugo sam bio siguran da ga koriste svi bez izuzetka. Ispostavilo se da je to rijetkost.
Pored onoga što sam spomenuo tokom izvještaja, postoje nedokumentirane karakteristike koje vam omogućavaju da napadnete klaster. Objavljeno nedavno .
Neke stvari su tako tužne i bolne. Na primjer, pod određenim uvjetima, kubeleti u Kubernetes klasteru mogu dati sadržaj direktorija čarobnjaka i to neovlaštenom korisniku.
postoje uputstva kako da reprodukujem sve što sam rekao. Postoje datoteke sa primjerima proizvodnje, kako izgledaju ResourceQuota, Pod Security Policy. I sve ovo se može dodirnuti.
Hvala svima.
izvor: www.habr.com