Pavel Selivanov, architekt řešení Southbridge a učitel Slurm, měl přednášku na DevOpsConf 2019. Tato přednáška je součástí jednoho z témat kurzu Slurm Mega advanced Kubernetes.
se koná v Moskvě ve dnech 18. – 20. listopadu.
- Moskva, 22.-24. listopadu.
vždy dostupný.
Pod střihem - přepis zprávy.
Dobré odpoledne, kolegové a sympatizanti. Dnes budu mluvit o bezpečnosti.
Vidím, že dnes je v hale spousta lidí z ochranky. Předem se vám omlouvám, pokud budu používat termíny ze světa bezpečnosti ne úplně tak, jak to obvykle děláte.
Stalo se, že asi před šesti měsíci mi padl do rukou jeden veřejný cluster Kubernetes. Public - znamená, že existuje n-tý počet jmenných prostorů, v těchto jmenných prostorech jsou uživatelé izolovaní ve svém jmenném prostoru. Všichni tito uživatelé patří k různým společnostem. Předpokládalo se, že tento cluster by měl být použit jako CDN. To znamená, že vám dají shluk, dají tam uživatele, jdete tam ve svém jmenném prostoru, rozmístíte své fronty.
Moje předchozí společnost se snažila takovou službu prodat. A byl jsem požádán, abych se vrhl do shluku na toto téma - zda je takové řešení vhodné nebo ne.
Přišel jsem do tohoto shluku. Dostal jsem omezená práva, omezený jmenný prostor. Tam kluci pochopili, co je bezpečnost. Přečetli si, co je Role-based access control (RBAC) v Kubernetes – a překroutili to tak, že jsem nemohl spouštět pody odděleně od nasazení. Nepamatuji si problém, který jsem se snažil vyřešit spuštěním modulu bez nasazení, ale opravdu jsem chtěl spustit pouze modul. Rozhodl jsem se pro štěstí, abych viděl, jaká práva v clusteru mám, co můžu, co ne, co tam podělali. Zároveň vám řeknu, co v RBAC špatně nakonfigurovali.
Stalo se, že za dvě minuty jsem dostal admina do jejich clusteru, podíval se na všechny sousední jmenné prostory, viděl produkční fronty firem, které už službu koupily a nasadily tam. Sotva jsem se zastavil, abych nepřišel k někomu vepředu a nedal na hlavní stránku nějaké nadávky.
Řeknu vám na příkladech, jak jsem to udělal a jak se proti tomu bránit.
Nejprve mi však dovolte, abych se představil. Jmenuji se Pavel Selivanov. Jsem architekt pro Southbridge. Rozumím Kubernetes, DevOps a všem možným věcem. Inženýři Southbridge a já to všechno stavíme a já konzultuji.
Kromě našich hlavních aktivit jsme v poslední době rozjeli projekty s názvem Slurms. Snažíme se naši schopnost pracovat s Kubernetes trochu přiblížit masám, naučit další lidi, jak pracovat s K8s.
O čem dnes budu mluvit. Téma zprávy je zřejmé – o zabezpečení clusteru Kubernetes. Ale chci hned říci, že toto téma je velmi rozsáhlé - a proto chci hned upřesnit, o čem rozhodně nebudu mluvit. Nebudu mluvit o otřepaných termínech, které už byly na internetu stokrát nadužívané. Jakékoli RBAC a certifikáty.
Budu mluvit o tom, co bolí mě a mé kolegy z bezpečnosti v clusteru Kubernetes. Tyto problémy vidíme jak u poskytovatelů, kteří poskytují clustery Kubernetes, tak u klientů, kteří k nám přicházejí. A to i pro klienty, kteří k nám přicházejí z jiných poradenských admin společností. To znamená, že rozsah tragédie je ve skutečnosti velmi velký.
Doslova tři body, o kterých dnes budu mluvit:
- Uživatelská práva vs práva pod. Uživatelská práva a práva pod nejsou totéž.
- Sběr informací o clusteru. Ukážu, že můžete shromažďovat všechny informace, které potřebujete z clusteru, aniž byste v tomto clusteru měli zvláštní práva.
- DoS útok na cluster. Pokud se nám nepodaří shromáždit informace, budeme moci cluster umístit v každém případě. Budu mluvit o DoS útocích na prvky řízení clusteru.
Další obecná věc, kterou zmíním, je to, na čem jsem to všechno testoval, na čemž mohu s jistotou říci, že to celé funguje.
Jako základ bereme instalaci clusteru Kubernetes pomocí Kubespray. Pokud někdo neví, jedná se vlastně o sadu rolí pro Ansible. V práci ho používáme neustále. Dobrá věc je, že se můžete válet kdekoli - a můžete se válet po kusech železa a někde v oblaku. Jeden způsob instalace je vhodný v zásadě pro vše.
V tomto clusteru budu mít Kubernetes v1.14.5. Celý cluster Cube, který budeme uvažovat, je rozdělen do jmenných prostorů, každý jmenný prostor patří samostatnému týmu, členové tohoto týmu mají přístup ke každému jmennému prostoru. Nemohou přejít do různých jmenných prostorů, pouze do svých vlastních. Existuje však určitý administrátorský účet, který má práva na celý cluster.
Slíbil jsem, že první věcí, kterou budeme mít, je získání administrátorských práv ke clusteru. Potřebujeme speciálně připravený modul, který rozbije cluster Kubernetes. Vše, co musíme udělat, je aplikovat jej na cluster Kubernetes.
kubectl apply -f pod.yamlTento modul přijde k jednomu z mistrů clusteru Kubernetes. A cluster poté šťastně vrátí soubor s názvem admin.conf. Na Kubě jsou v tomto souboru uloženy všechny administrátorské certifikáty a zároveň se konfiguruje cluster API. Myslím, že takto snadné je získat přístup správce k 98 % clusterů Kubernetes.
Opět, tento modul byl vytvořen jedním vývojářem ve vašem clusteru, který má přístup k nasazení svých návrhů do jednoho malého jmenného prostoru, je celý pod kontrolou RBAC. Neměl žádná práva. Ale přesto se certifikát vrátil.
A nyní o speciálně upraveném ohništi. Spouštíme na jakémkoli obrázku. Vezměme si jako příklad debian:jessie.
Máme něco takového:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Co je tolerance? Mastery v clusteru Kubernetes jsou obvykle označeny věcí zvanou taint. A podstatou této „infekce“ je, že říká, že pody nelze přiřadit k hlavním uzlům. Ale nikdo se neobtěžuje v žádném pouzdru naznačit, že je tolerantní k „infekci“. Sekce Toleration jen říká, že pokud je NoSchedule nainstalován na nějakém uzlu, pak je náš modul k takové infekci tolerantní - a nejsou žádné problémy.
Dále říkáme, že náš lusk je nejen tolerantní, ale chce i schválně zasáhnout pána. Protože mistři mají to nejchutnější, co potřebujeme - všechny certifikáty. Proto říkáme nodeSelector – a na masterech máme standardní popisek, který umožňuje vybrat ze všech uzlů clusteru právě ty uzly, které jsou mastery.
S těmito dvěma úseky to na mistra určitě přijde. A bude mu tam dovoleno žít.
Ale jen přijít k pánovi nám nestačí. Nic nám to nedá. Takže dále máme tyto dvě věci:
hostNetwork: true
hostPID: true Určujeme, že náš modul, který provozujeme, bude žít v jmenném prostoru jádra, síťovém jmenném prostoru a jmenném prostoru PID. Jakmile modul běží na hlavním serveru, bude schopen vidět všechna skutečná živá rozhraní tohoto uzlu, poslouchat veškerý provoz a vidět PID všech procesů.
Pak už je to na maličkostech. Vezmi si etcd a přečti si co chceš.
Nejzajímavější je tato funkce Kubernetes, která je zde ve výchozím nastavení.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host A jeho podstatou je, že můžeme v podu, který spustíme, i bez práv k tomuto clusteru, říci, že chceme vytvořit svazek typu hostPath. Vezměte si tedy cestu od hostitele, na které budeme začínat – a berte to jako objem. A pak tomu říkáme jméno: hostitel. Všechny tyto hostPath namontujeme dovnitř modulu. V tomto příkladu do adresáře /host.
Ještě jednou se budu opakovat. Řekli jsme podu, aby přišel k hlavnímu modulu, získal tam hostNetwork a hostPID – a namontoval celý kořen hlavního modulu do tohoto modulu.
Chápete, že v debianu máme spuštěný bash a tento bash nám funguje jako root. To znamená, že jsme právě získali root na hlavním serveru, ale nemáme žádná práva v clusteru Kubernetes.
Pak je celým úkolem jít do adresáře / host / etc / kubernetes / pki, pokud se nemýlím, vyzvednout tam všechny hlavní certifikáty clusteru a podle toho se stát správcem clusteru.
Při tomto pohledu jde o některá z nejnebezpečnějších práv v podech, bez ohledu na to, jaká práva má uživatel:
Pokud mám práva ke spuštění podu v nějakém jmenném prostoru clusteru, pak tento pod má tato práva ve výchozím nastavení. Mohu spouštět privilegované moduly, což jsou obecně všechna práva, prakticky rootování uzlu.
Můj oblíbený je uživatel root. A Kubernetes má tuto možnost Run As Non-Root. Jedná se o typ ochrany proti hackerům. Víte, co je to „moldavský virus“? Pokud jste najednou hacker a přišli jste do mého clusteru Kubernetes, pak se my, chudí administrátoři, ptáme: „Uveďte prosím ve svých podech, s nimiž hacknete můj cluster, spustit jako non-root. Jinak to dopadne tak, že proces spustíte ve svém podu pod kořenem a bude pro vás velmi snadné mě hacknout. Chraňte se, prosím."
Objem cesty hostitele – podle mého názoru nejrychlejší způsob, jak získat požadovaný výsledek z clusteru Kubernetes.
Ale co s tím vším dělat?
Myšlenky, které by měly napadnout každého normálního správce, který se setká s Kubernetes: „Jo, říkal jsem vám, Kubernetes nefunguje. Má v sobě díry. A celá kostka je svinstvo.“ Ve skutečnosti existuje něco jako dokumentace, a když se tam podíváte, pak je tam sekce .
Jedná se o takový yaml objekt – můžeme jej vytvořit v clusteru Kubernetes – který řídí bezpečnostní aspekty v popisu podů. To znamená, že ve skutečnosti řídí práva k použití jakékoli hostitelské sítě, hostitelského PID a určitých typů svazků, které jsou v modulech při spuštění. To vše lze popsat pomocí bezpečnostní politiky Pod.
Nejzajímavější na bezpečnostní politice Pod je to, že v clusteru Kubernetes nejsou všechny instalátory PSP jen tak nějak popsány, jsou prostě ve výchozím nastavení vypnuté. Zásady zabezpečení pod se povolují pomocí přijímacího pluginu.
Dobře, nasadíme bezpečnostní politiku pod do clusteru, řekněme, že máme ve jmenném prostoru nějaké moduly služeb, ke kterým mají přístup pouze administrátoři. Řekněme, že ve všem ostatním mají pody omezená práva. Protože vývojáři s největší pravděpodobností nemusí na vašem clusteru spouštět privilegované moduly.
A zdá se, že jsme v pohodě. A náš cluster Kubernetes nelze hacknout za dvě minuty.
Vyskytl se problém. S největší pravděpodobností, pokud máte cluster Kubernetes, je monitorování nainstalováno ve vašem clusteru. Dokonce se zavazuji předpovědět, že pokud má váš cluster monitorování, pak se nazývá Prometheus.
To, co vám nyní řeknu, bude platit jak pro operátora Prometheus, tak pro Prometheus dodávaný v čisté podobě. Otázkou je, že pokud se mi nepodaří získat administrátora do clusteru tak rychle, znamená to, že musím více hledat. A můžu hledat pomocí vašeho sledování.
Pravděpodobně všichni čtou stejné články o Habrém a monitoring se nachází v monitoringu jmenného prostoru. Helm chart se nazývá přibližně stejně pro všechny. Domnívám se, že pokud nainstalujete helm stable/prometheus, měli byste skončit se zhruba stejnými jmény. A dokonce s největší pravděpodobností nebudu muset hádat název DNS ve vašem clusteru. Protože je to standardní.
Dále máme určitý vývoj, ve kterém můžete spustit určitý modul. A pak z tohoto modulu je velmi snadné to udělat takto:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics je jedním z exportérů prometheus, který shromažďuje metriky ze samotného Kubernetes API. Je tam spousta dat, co ve vašem clusteru běží, co to je, jaké s tím máte problémy.
Jako jednoduchý příklad:
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
Informace, jako je tato, můžete získat jednoduchým požadavkem na zvlnění z neprivilegovaného modulu. Pokud nevíte, jakou verzi Kubernetes používáte, snadno vám to řekne.
A nejzajímavější je, že kromě toho, že přistupujete ke kube-state-metrics, můžete stejně dobře přistupovat přímo k samotnému Prometheus. Odtud můžete sbírat metriky. Odtud můžete dokonce vytvářet metriky. I teoreticky si takový dotaz můžete sestavit z clusteru v Prometheus, který jej jednoduše vypne. A vaše monitorování obecně přestane fungovat z clusteru.
A zde se již nabízí otázka, zda nějaký externí monitoring hlídá váš monitoring. Právě jsem dostal příležitost pracovat v clusteru Kubernetes bez jakýchkoli následků pro mě. Ani nebudete vědět, že tam pracuji, protože tam už není monitorování.
Stejně jako u PSP se zdá, že problém je v tom, že všechny tyhle luxusní technologie - Kubernetes, Prometheus - prostě nefungují a jsou plné děr. Spíš ne.
Existuje taková věc - .
Pokud jste normální admin, tak o Network Policy nejspíš víte, že se jedná o další yaml, kterých už jsou v clusteru dofiga. A síťové zásady rozhodně nejsou potřeba. A i když si přečtete, co je to Network Policy, co je Kubernetes yaml firewall, umožňuje vám to omezit přístupová práva mezi jmennými prostory, mezi pody, pak jste se definitivně rozhodli, že yaml firewall v Kubernetes je založen na dalších abstrakcích ... Ne -ne. Rozhodně to není nutné.
I když vašim bezpečnostním specialistům nebylo řečeno, že s pomocí vašeho Kubernetes můžete vytvořit velmi snadný a jednoduchý firewall a velmi podrobný. Pokud to ještě nevědí a netahají vás: „No, dej to, dej to...“ Pak v každém případě potřebujete Zásady sítě, abyste zablokovali přístup k některým servisním místům, která můžete stáhnout ze svého clusteru bez jakéhokoli oprávnění.
Stejně jako v příkladu, který jsem uvedl, můžete vytáhnout metriky stavu kube z libovolného jmenného prostoru v clusteru Kubernetes, aniž byste k tomu měli jakákoli práva. Síťové zásady uzavřely přístup ze všech ostatních jmenných prostorů k monitorovacímu jmennému prostoru a jakoby ke všemu: žádný přístup, žádné problémy. Ve všech existujících grafech, jak ve standardním prometheus, tak v prometheus, který je v operátorovi, existuje jednoduše možnost v hodnotách kormidla jednoduše pro ně povolit síťové zásady. Stačí je zapnout a budou fungovat.
Tady je opravdu jeden problém. Jako normální vousatý správce jste se s největší pravděpodobností rozhodli, že síťové zásady nejsou potřeba. A po přečtení nejrůznějších článků o zdrojích, jako je Habr, jste se rozhodli, že flanel, zejména s režimem hostitel-brána, je to nejlepší, co si můžete vybrat.
Co dělat?
Můžete zkusit znovu nasadit síťové řešení, které máte ve svém Kubernetes clusteru, zkuste ho nahradit něčím funkčnějším. Na stejném Calico, například. Ale hned chci říct, že úkol změnit síťové řešení ve funkčním clusteru Kubernetes je docela netriviální. Řešil jsem to dvakrát (obakrát ovšem teoreticky), ale dokonce jsme si na Slurmech ukázali, jak na to. Pro naše studenty jsme ukázali, jak změnit síťové řešení v clusteru Kubernetes. V zásadě se můžete pokusit zajistit, aby na produkčním clusteru nedocházelo k výpadkům. Ale to se vám asi nepodaří.
A problém je vlastně vyřešen velmi jednoduše. V clusteru jsou certifikáty a vy víte, že se vám certifikáty za rok pokazí. No a většinou normální řešení s certifikáty v clusteru - proč se budeme pouštět do parní lázně, zvedneme vedle něj nový cluster, necháme ho shnít v tom starém a všechno přemístíme. Pravda, když to shnije, všechno na den poleží, ale pak nový shluk.
Když zvednete nový cluster, současně vložte Calico místo flanelu.
Co dělat v případě, že máte certifikáty vydané na sto let a nechystáte se na redislokaci clusteru? Existuje taková věc Kube-RBAC-Proxy. Toto je velmi skvělý vývoj, umožňuje vám vložit se jako kontejner postranního vozíku do libovolného modulu v clusteru Kubernetes. A ve skutečnosti do tohoto modulu přidává autorizaci prostřednictvím RBAC samotného Kubernetes.
Je tu jeden problém. Dříve bylo toto řešení Kube-RBAC-Proxy zabudováno do prometheus operátora. Ale pak byl pryč. Moderní verze nyní spoléhají na to, že máte síťové zásady a uzavřete je jimi. A tak musíte graf trochu přepsat. Ve skutečnosti, pokud půjdete do , existují příklady, jak to použít jako postranní vozíky a grafy se budou muset minimálně přepisovat.
Je tu ještě jeden malý problém. Nejen Prometheus rozdává své metriky komukoli. V našem případě jsou všechny součásti clusteru Kubernetes také schopny poskytnout své metriky.
Ale jak jsem řekl, pokud se nemůžete dostat do clusteru a sbírat informace, můžete alespoň ublížit.
Rychle vám tedy ukážu dva způsoby, jak může cluster Kubernetes onemocnět.
Budete se smát, když vám řeknu, že to jsou dva případy ze skutečného života.
Metoda jedna. Vyčerpání zdrojů.
Spouštíme další speciální modul. Bude mít tuto sekci.
resources:
requests:
cpu: 4
memory: 4Gi Jak víte, požadavky jsou množství CPU a paměti, které je vyhrazeno na hostiteli pro konkrétní moduly požadavků. Pokud máme čtyřjádrového hostitele v clusteru Kubernetes a čtyři CPU pody tam dorazí s požadavky, pak už na tohoto hostitele nemohou přijít žádné pody s požadavky.
Pokud spustím takový modul, vydám příkaz:
$ kubectl scale special-pod --replicas=...Nikdo jiný pak nebude moci nasadit do clusteru Kubernetes. Protože všem uzlům dojdou požadavky. A tak zastavím váš cluster Kubernetes. Když to udělám večer, tak se nasazení dá zastavit na docela dlouhou dobu.
Pokud se znovu podíváme do dokumentace Kubernetes, uvidíme něco takového s názvem Limit Range. Nastavuje prostředky pro objekty clusteru. Můžete napsat objekt Limit Range v yaml, aplikovat jej na určité jmenné prostory – a dále v tomto jmenném prostoru můžete říci, že máte prostředky pro výchozí, maximální a minimální pody.
S pomocí takové věci můžeme uživatelům v konkrétních jmenných prostorech týmových produktů omezit možnost označovat na svých modulech nejrůznější ošklivé věci. Ale bohužel, i když uživateli řeknete, že nemůžete spouštět moduly s požadavky na více než jeden CPU, existuje takový úžasný příkaz scale, dobře, nebo prostřednictvím řídicího panelu mohou provádět škálování.
A tady přichází na řadu číslo dvě. Běžte 11 111 111 111 111 pod. Jde o jedenáct miliard. Není to proto, že jsem na takové číslo přišel, ale proto, že jsem ho sám viděl.
Opravdový příběh. Pozdě večer jsem se chystal odejít z kanceláře. Koukám, skupina vývojářů sedí v rohu a zběsile něco dělá s notebooky. Jdu za klukama a ptám se: "Co se ti stalo?"
O něco dříve, v devět hodin večer, se jeden z vývojářů chystal domů. A rozhodl jsem se: "Nyní přizpůsobím svou aplikaci na jednu." Stiskl jsem jeden a internet byl trochu nudný. Znovu stiskl jedničku, stiskl jedničku a zmáčkl Enter. Strkal všechno, co mohl. Pak ožil internet – a vše se začalo škálovat až k tomuto datu.
Pravda, tento příběh se neodehrával na Kubernetes, v té době to byl Nomad. Skončilo to tím, že po hodině našich pokusů zastavit Nomada od zarputilých pokusů o škálování, Nomad odpověděl, že škálovat nepřestane a nebude dělat nic jiného. "Jsem unavený, odcházím." A otočil se.
Přirozeně jsem se pokusil udělat totéž na Kubernetes. Jedenáct miliard lusků Kubernetes nepotěšil, řekl: „Nemohu. Přesahuje vnitřní uzávěry. Ale 1 000 000 000 lusků by mohlo.
V reakci na jednu miliardu se kostka nestáhla do sebe. Opravdu se začal zmenšovat. Čím dále proces šel, tím více času trvalo vytvoření nových lusků. Ale přesto proces pokračoval. Jediný problém je v tom, že když můžu spouštět pody ve svém jmenném prostoru donekonečna, tak i bez požadavků a limitů dokážu s některými úkoly spouštět takový počet podů, že se pomocí těchto úkolů začnou uzly sčítat z paměti, na CPU. Když spustím tolik podů, informace z nich se musí dostat do úložiště, tedy atd. A když přijde příliš mnoho informací, úložiště se začne vracet příliš pomalu – a Kubernetes se začne otupovat.
A ještě jeden problém... Jak víte, ovládací prvky Kubernetes nejsou nějaká centrální věc, ale několik komponent. Tam je zejména správce kontroléru, plánovač a tak dále. Všichni tihle chlapi začnou dělat zbytečnou hloupou práci zároveň, která jim časem začne zabírat víc a víc času. Správce ovladače vytvoří nové moduly. Plánovač se pro ně pokusí najít nový uzel. Nové uzly ve vašem clusteru s největší pravděpodobností brzy dojdou. Cluster Kubernetes začne běžet stále pomaleji.
Ale rozhodl jsem se jít ještě dál. Jak víte, Kubernetes má věc zvanou služba. Ve výchozím nastavení ve vašich clusterech služba s největší pravděpodobností funguje pomocí tabulek IP.
Pokud například spustíte jednu miliardu modulů a poté pomocí skriptu přinutíte Kubernetis vytvořit nové služby:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Na všech uzlech clusteru bude přibližně současně generováno více a více nových pravidel iptables. Navíc bude pro každou službu vygenerována jedna miliarda pravidel iptables.
Zkontroloval jsem to celé na několika tisících až desítkách. A problém je v tom, že už na tomto prahu je dost problematické udělat ssh do uzlu. Protože pakety, procházející tolika řetězci, se začínají cítit ne příliš dobře.
A to je také vše vyřešeno pomocí Kubernetes. Existuje taková kvóta prostředků na objekt. Nastavuje počet dostupných prostředků a objektů pro obor názvů v clusteru. V každém jmenném prostoru clusteru Kubernetes můžeme vytvořit objekt yaml. Pomocí tohoto objektu můžeme říci, že máme pro tento jmenný prostor přidělen určitý počet požadavků, limity a dále můžeme říci, že v tomto jmenném prostoru je možné vytvořit 10 služeb a 10 podů. A jediný vývojář se může po večerech i drtit. Kubernetes mu řekne: "Nemůžete škálovat své pody na takové množství, protože to překračuje kvótu zdrojů." To je vše, problém vyřešen. .
V souvislosti s tím vyvstává jeden problém. Cítíte, jak obtížné je vytvořit jmenný prostor v Kubernetes. Abychom jej vytvořili, musíme vzít v úvahu spoustu věcí.
Kvóta zdrojů + limitní rozsah + RBAC
• Vytvořte jmenný prostor
• Vytvořte vnitřní limitní rozsah
• Vytvořte vnitřní kvótu zdrojů
• Vytvořte servisní účet pro CI
• Vytvořte rolebinding pro CI a uživatele
• Volitelně spusťte potřebné servisní moduly
Proto bych se při této příležitosti rád podělil o svůj vývoj. Existuje taková věc, která se nazývá operátor SDK. Toto je způsob, jak pro něj v clusteru Kubernetes psát příkazy. Můžete psát prohlášení s Ansible.
Nejprve jsme psali v Ansible a pak jsem se podíval, co je to SDK operátor, a přepsal jsem roli Ansible na operátor. Tento příkaz umožňuje vytvořit objekt v clusteru Kubernetes nazývaný příkaz. Uvnitř příkazu vám umožňuje popsat prostředí pro tento příkaz v yaml. A uvnitř týmového prostředí nám umožňuje popsat, že alokujeme tolik zdrojů.
Drobounký .
A na závěr. Co s tím vším dělat?
První. Bezpečnostní politika pod je dobrá. A přestože je dodnes žádný z instalátorů Kubernetes nepoužívá, stále je musíte používat ve svých clusterech.
Síťová politika není nějaká další zbytečná funkce. To je to, co je v clusteru skutečně potřeba.
LimitRange / ResourceQuota - je čas použít. Začali jsme ho používat už dávno a dlouho jsem si byl jistý, že ho používá každý bez výjimky. Ukázalo se, že je to vzácné.
Kromě toho, co jsem zmínil během zprávy, existují nezdokumentované funkce, které vám umožňují zaútočit na cluster. Vydáno nedávno .
Některé věci jsou tak smutné a zraňující. Například za určitých podmínek mohou cubelety v clusteru Kubernetes poskytnout obsah adresáře warlocks a neoprávněnému uživateli.
existuje návod, jak reprodukovat vše, co jsem řekl. Jsou tam soubory s produkčními příklady, jak ResourceQuota, Pod Security Policy vypadají. A toho všeho se lze dotknout.
Děkuji vám všem.
Zdroj: www.habr.com