V roce 2010 společnost existovalo 50 serverů a jednoduchý model sítě: backend, frontend a firewall. Počet serverů rostl, model se stal složitějším: staging, izolované VLAN s ACL, pak VPN s VRF, VLAN s ACL na L2, VRF s ACL na L3. Točí se hlava? Později to bude zábavnější.
Když bylo 16 000 serverů, bylo nemožné pracovat bez slz s tolika heterogenními segmenty. Tak jsme přišli s jiným řešením. Vzali jsme zásobník Netfilter, přidali jsme k němu Consul jako zdroj dat a dostali jsme rychlý distribuovaný firewall. Nahradili ACL na routerech a použili je jako externí a interní firewall. Pro dynamickou správu nástroje jsme vyvinuli systém BEFW, který se používal všude: od správy uživatelského přístupu k produktové síti až po izolování segmentů sítě od sebe navzájem.
Prozradí vám, jak to celé funguje a proč byste se na tento systém měli podívat blíže. Ivan Agarkov () je vedoucím skupiny zabezpečení infrastruktury divize Údržba ve vývojovém centru společnosti v Minsku. Ivan je fanouškem SELinuxu, miluje Perl a píše kód. Jako vedoucí skupiny pro informační bezpečnost pravidelně pracuje s logy, zálohami a R&D, aby ochránil Wargaming před hackery a zajistil provoz všech herních serverů ve společnosti.
Historické informace
Než vám řeknu, jak jsme to udělali, řeknu vám, jak jsme k tomu přišli a proč to bylo potřeba. Abychom to udělali, vraťme se o 9 let zpět: v roce 2010 se právě objevil World of Tanks. Wargaming měl přibližně 50 serverů.
Graf růstu firemního serveru.
Měli jsme síťový model. Na tu dobu to bylo optimální.
Model sítě v roce 2010.
Na frontendu jsou padouši, kteří nás chtějí zlomit, ale má firewall. Na backendu není firewall, ale je tam 50 serverů, všechny je známe. Všechno funguje dobře.
Za 4 roky se flotila serverů rozrostla 100krát, na 5000. Objevily se první izolované sítě – inscenace: nemohly jít do výroby a často tam běžely věci, které mohly být nebezpečné.
Model sítě v roce 2014.
Setrvačností jsme použili stejné kusy hardwaru a veškerá práce byla provedena na izolovaných VLAN: ACL se zapisují do VLAN, které umožňují nebo zakazují nějaký druh připojení.
V roce 2016 dosáhl počet serverů 8000 XNUMX. Wargaming pohltil další studia a objevily se další affiliate sítě. Zdá se, že jsou naše, ale ne tak docela: VLAN často partnerům nefunguje, musíte používat VPN s VRF, izolace se stává složitější. Izolační směs ACL rostla.
Model sítě v roce 2016.
Do začátku roku 2018 se flotila strojů rozrostla na 16 000. Segmentů bylo 6 a zbytek, včetně uzavřených, ve kterých byla uložena finanční data, jsme nepočítali. Objevily se kontejnerové sítě (Kubernetes), DevOps, cloudové sítě připojené přes VPN například z IVS. Bylo tam hodně pravidel – bylo to bolestivé.
Síťový model a metody izolace v roce 2018.
Pro izolaci jsme použili: VLAN s ACL na L2, VRF s ACL na L3, VPN a mnoho dalšího. Příliš mnoho.
Problémy
Každý žije s ACL a VLAN. Co je špatně? Na tuto otázku Harold odpoví a skryje bolest.
Problémů bylo mnoho, ale bylo jich pět obrovských.
- Geometrické zvýšení cen pro nová pravidla. Každé nové pravidlo se přidávalo déle než to předchozí, protože bylo nutné nejprve zjistit, zda již takové pravidlo existuje.
- Žádný firewall uvnitř segmentů. Segmenty byly od sebe nějak odděleny a uvnitř už nebylo dost zdrojů.
- Pravidla platila dlouhou dobu. Operátoři mohli ručně napsat jedno místní pravidlo za hodinu. Ta globální trvala několik dní.
- Potíže s pravidly auditu. Přesněji řečeno to nebylo možné. První pravidla byla sepsána již v roce 2010 a většina jejich autorů již pro společnost nepracovala.
- Nízká úroveň kontroly infrastruktury. To je hlavní problém – moc dobře jsme nevěděli, co se v naší zemi děje.
Takto vypadal síťový inženýr v roce 2018, když slyšel: „Potřebuji další ACL.“
Řešení
Na začátku roku 2018 bylo rozhodnuto s tím něco udělat.
Cena integrací neustále roste. Výchozím bodem bylo, že velká datová centra přestala podporovat izolované VLAN a ACL, protože zařízením došla paměť.
Řešení: odstranili jsme lidský faktor a zautomatizovali poskytování přístupu na maximum.
Nová pravidla se uplatní dlouho. Řešení: urychlit aplikaci pravidel, učinit ji distribuovanou a paralelní. To vyžaduje distribuovaný systém, aby se pravidla doručovala sama, bez rsync nebo SFTP do tisíce systémů.
Žádný firewall uvnitř segmentů. Firewall v rámci segmentů k nám začal přicházet, když se ve stejné síti objevily různé služby. Řešení: použijte firewall na úrovni hostitele – firewally založené na hostiteli. Téměř všude, kde máme Linux, a všude, kde máme iptables, to není problém.
Potíže s pravidly auditu. Řešení: Udržujte všechna pravidla na jednom místě pro kontrolu a správu, abychom mohli vše auditovat.
Nízká úroveň kontroly nad infrastrukturou. Řešení: Proveďte inventuru všech služeb a přístupů mezi nimi.
Jedná se spíše o administrativní než technický proces. Někdy máme 200-300 nových verzí týdně, zejména během akcí a svátků. Navíc je to jen pro jeden tým našich DevOps. S tolika vydáními není možné zjistit, jaké porty, adresy IP a integrace jsou potřeba. Potřebovali jsme proto speciálně vyškolené servisní manažery, kteří se týmů zeptali: „Co tam vlastně je a proč jste to uvedli?“
Po všem, co jsme spustili, začal síťový inženýr v roce 2019 vypadat takto.
Konzul
Rozhodli jsme se, že vše, co jsme našli s pomocí servisních manažerů, vložíme do Consul a odtud napíšeme pravidla iptables.
Jak jsme se k tomu rozhodli?
- Budeme shromažďovat všechny služby, sítě a uživatele.
- Na jejich základě vytvoříme pravidla iptables.
- Automatizujeme ovládání.
- ....
- ZISK.
Consul není vzdálené API, může běžet na každém uzlu a zapisovat do iptables. Nezbývá než vymyslet automatické ovládání, které nepotřebné věci uklidí, a většina problémů bude vyřešena! Zbytek dořešíme za pochodu.
Proč Consul?
Dobře se osvědčil. V letech 2014-15 jsme jej používali jako backend pro Vault, ve kterém ukládáme hesla.
Neztrácí data. Za dobu používání Consul nepřišel o data při jediné nehodě. To je obrovské plus pro systém správy firewallu.
P2P připojení urychluje šíření změn. S P2P přicházejí všechny změny rychle, není třeba čekat hodiny.
Pohodlné REST API. Zvažovali jsme také Apache ZooKeeper, ale ten nemá REST API, takže si budete muset nainstalovat berličky.
Funguje jako Key Vault (KV) i jako adresář (Service Discovery). Můžete ukládat služby, katalogy a datová centra najednou. To je výhodné nejen pro nás, ale i pro sousední týmy, protože při budování globální služby myslíme ve velkém.
Napsáno v Go, který je součástí Wargaming stacku. Milujeme tento jazyk, máme mnoho vývojářů Go.
Výkonný ACL systém. V Consul můžete pomocí ACL ovládat, kdo co píše. Garantujeme, že pravidla firewallu se nebudou překrývat s ničím jiným a nebudeme s tím mít problémy.
Ale Consul má také své nevýhody.
- Neškáluje se v datovém centru, pokud nemáte obchodní verzi. Je škálovatelný pouze podle federace.
- Velmi záleží na kvalitě sítě a vytížení serveru. Consul nebude správně fungovat jako server na zaneprázdněném serveru, pokud se v síti vyskytnou nějaké zpoždění, například nerovnoměrná rychlost. Důvodem je P2P připojení a modely distribuce aktualizací.
- Obtížnost sledování dostupnosti. Ve statusu konzul může říci, že je vše v pořádku, ale zemřel už dávno.
Většinu těchto problémů jsme vyřešili při použití Consul, a proto jsme si jej vybrali. Společnost má plány na alternativní backend, ale naučili jsme se řešit problémy a momentálně žijeme s Consul.
Jak Consul funguje
Nainstalujeme tři až pět serverů v podmíněném datovém centru. Jeden nebo dva servery nebudou fungovat: nebudou schopny zorganizovat kvorum a rozhodnout, kdo má pravdu a kdo se mýlí, když se data nebudou shodovat. Více než pět nemá smysl, produktivita klesne.
Klienti se připojují k serverům v libovolném pořadí: stejní agenti, pouze s příznakem server = false.
Poté klienti obdrží seznam P2P připojení a vytvoří mezi sebou spojení.
Na globální úrovni propojujeme několik datových center. Také propojují P2P a komunikují.
Když chceme získat data z jiného datového centra, požadavek jde ze serveru na server. Toto schéma se nazývá Poddaný protokol. Protokol Serf, stejně jako Consul, je vyvinut společností HashiCorp.
Několik důležitých faktů o konzulovi
Consul má dokumentaci popisující, jak to funguje. Uvedu pouze vybraná fakta, která stojí za to znát.
Konzulské servery vybírají pána z voličů. Consul vybere hlavní server ze seznamu serverů pro každé datové centrum a všechny požadavky směřují pouze na něj, bez ohledu na počet serverů. Master zmrazení nevede ke znovuzvolení. Pokud není vybrán master, požadavky nebudou obsluhovány nikým.
Chtěli jste horizontální měřítko? Promiň, ne.
Požadavek do jiného datového centra prochází od hlavního k hlavnímu bez ohledu na to, na který server přišel. Vybraný master obdrží 100 % zátěže, s výjimkou zátěže na předávací požadavky. Všechny servery v datovém centru mají aktuální kopii dat, ale pouze jeden odpovídá.
Jediným způsobem škálování je povolit zastaralý režim na klientovi.
V zastaralém režimu můžete reagovat bez kvora. Toto je režim, ve kterém se vzdáváme konzistence dat, ale čteme o něco rychleji než obvykle a jakýkoli server reaguje. Přirozeně nahrávání pouze přes master.
Consul nekopíruje data mezi datovými centry. Po sestavení federace bude mít každý server pouze svá vlastní data. U ostatních se vždy obrací na někoho jiného.
Atomicita operací není zaručena mimo transakci. Pamatujte, že nejste jediní, kdo může věci změnit. Pokud to chcete jinak, proveďte transakci se zámkem.
Blokovací operace nezaručují uzamčení. Požadavek jde od mastera k masteru, a ne přímo, takže není zaručeno, že blokování bude fungovat, když blokujete například v jiném datovém centru.
ACL také nezaručuje přístup (v mnoha případech). ACL nemusí fungovat, protože je uložen v jednom federačním datovém centru – v datovém centru ACL (Primary DC). Pokud vám DC neodpoví, ACL nebude fungovat.
Jeden zamrzlý mistr způsobí zamrznutí celé federace. Například ve federaci je 10 datových center a jedno má špatnou síť a jedno hlavní selže. Každý, kdo s ním komunikuje, uvízne v kruhu: existuje žádost, není na ni odpověď, vlákno zamrzne. Neexistuje způsob, jak vědět, kdy se to stane, prostě za hodinu nebo dvě padne celá federace. S tím se nedá nic dělat.
Stav, kvorum a volby jsou řešeny samostatným vláknem. Znovuzvolení neproběhne, status nic neukáže. Myslíte si, že máte živého konzula, zeptáte se a nic se neděje – neexistuje žádná odpověď. Zároveň stav ukazuje, že je vše v pořádku.
Setkali jsme se s tímto problémem a museli jsme přestavět konkrétní části datových center, abychom se mu vyhnuli.
Obchodní verze Consul Enterprise nemá některé z výše uvedených nevýhod. Má mnoho užitečných funkcí: výběr voličů, distribuci, škálování. Existuje pouze jedno „ale“ - licenční systém pro distribuovaný systém je velmi drahý.
Life hacking: rm -rf /var/lib/consul - lék na všechny choroby původce. Pokud vám něco nefunguje, jednoduše svá data smažte a stáhněte si data z kopie. S největší pravděpodobností bude konzul fungovat.
BEFW
Nyní si promluvme o tom, co jsme přidali do Consul.
je zkratka pro BackEndFhněvWVšechno. Při vytváření úložiště jsem musel produkt nějak pojmenovat, abych do něj vložil první testovací commity. Toto jméno zůstává.
Šablony pravidel
Pravidla jsou napsána v syntaxi iptables.
- -N PŘED
- -P POKRAČOVÁNÍ VSTUPU
- -A VSTUP -m stav—stav SOUVISEJÍCÍ,UZASTAVEN -j PŘIJAT
- -A VSTUP -i lo -j PŘIJÍMAT
- -A VSTUP -j BEFW
Všechno jde do řetězce BEFW, kromě ESTABLISHED, RELATED a localhost. Šablona může být jakákoli, toto je jen příklad.
Jak je BEFW užitečný?
Služby
Máme službu, ta má vždy port, uzel, na kterém běží. Z našeho uzlu se můžeme lokálně zeptat agenta a zjistit, že máme nějakou službu. Můžete také umístit značky.
Jakákoli služba, která je spuštěna a registrována u Consul, se změní na pravidlo iptables. Máme SSH - otevřený port 22. Skript Bash je jednoduchý: curl a iptables, nic jiného není potřeba.
Zákazníci
Jak otevřít přístup ne všem, ale selektivně? Přidejte seznamy IP do úložiště KV podle názvu služby.
Například chceme, aby každý v desáté síti měl přístup ke službě SSH_TCP_22. Přidat jedno malé pole TTL? a teď máme dočasná povolení třeba na den.
Přístupy
Propojujeme služby a klienty: máme službu, pro každého je připraveno úložiště KV. Nyní poskytujeme přístup ne všem, ale selektivně.
Skupina
Pokud budeme pokaždé psát tisíce IP pro přístup, unaví nás to. Vymyslíme seskupení – samostatná podmnožina v KV. Říkejme tomu Alias (nebo skupiny) a ukládejte tam skupiny podle stejného principu.
Pojďme se připojit: nyní můžeme otevřít SSH ne speciálně pro P2P, ale pro celou skupinu nebo několik skupin. Stejně tak je tu TTL - můžete přidat do skupiny a dočasně odebrat ze skupiny.
Integrace
Naším problémem je lidský faktor a automatizace. Zatím jsme to řešili takto.
S Puppet pracujeme a přenášíme do nich vše, co se týká systému (kód aplikace). Puppetdb (běžný PostgreSQL) ukládá seznam služeb, které tam běží, lze je najít podle typu zdroje. Tam se dozvíte, kdo se kam hlásí. K tomu máme také systém žádostí o stažení a sloučení.
Napsali jsme befw-sync, jednoduché řešení, které pomáhá přenášet data. Nejprve k synchronizačním souborům cookie přistupuje puppetdb. Je tam nakonfigurováno HTTP API: požadujeme, jaké služby máme, co je potřeba udělat. Poté podají žádost konzulovi.
Existuje integrace? Ano: napsali pravidla a umožnili přijímat žádosti o stažení. Potřebujete určitý port nebo přidat hostitele do nějaké skupiny? Vytáhněte požadavek, zkontrolujte – už žádné „Najděte 200 dalších ACL a zkuste s tím něco udělat.“
Optimalizace
Ping na localhost s prázdným řetězcem pravidel trvá 0,075 ms.
Přidejme do tohoto řetězce 10 000 adres iptables. V důsledku toho se ping zvýší 5krát: iptables je zcela lineární, zpracování každé adresy nějakou dobu trvá.
Pro firewall, kde migrujeme tisíce ACL, máme spoustu pravidel, což zavádí latenci. To je špatné pro herní protokoly.
Ale když položíme 10 000 adres v IPsetu Ping se dokonce sníží.
Jde o to, že „O“ (složitost algoritmu) pro ipset je vždy rovno 1, bez ohledu na to, kolik pravidel existuje. Pravda, existuje omezení – pravidel nemůže být více než 65535 XNUMX. Zatím žijeme s tímto: můžete je kombinovat, rozšiřovat, vytvářet dva ipsety v jednom.
Opatrování
Logickým pokračováním procesu iterace je ukládání informací o klientech pro službu do ipsetu.
Nyní máme stejné SSH a nezapisujeme 100 IP najednou, ale nastavujeme název ipsetu, se kterým potřebujeme komunikovat, a následující pravidlo DROP. Dá se to převést na jedno pravidlo „Kdo tu není, DROP“, ale je to jasnější.
Nyní máme pravidla a soubory. Hlavním úkolem je vytvořit sadu před napsáním pravidla, protože jinak iptables pravidlo nezapíše.
Obecné schéma
Ve formě diagramu vše, co jsem řekl, vypadá takto.
Zavazujeme se k Puppet, vše se posílá na hostitele, služby sem, ipset tam a kdo tam není registrován, nesmí.
Umožňují popřít
Abychom rychle zachránili svět nebo rychle někoho znemožnili, na začátku všech řetězců jsme vytvořili dva ipsety: rules_allow и rules_deny. Jak to funguje?
Někdo například vytváří zátěž na našem webu pomocí robotů. Dříve jste museli najít jeho IP z protokolů, předat ji síťovým inženýrům, aby mohli najít zdroj provozu a zakázat ho. Teď to vypadá jinak.
Odešleme to konzulovi, počkáme 2,5 sekundy a je hotovo. Vzhledem k tomu, že Consul rychle distribuuje prostřednictvím P2P, funguje všude a v jakékoli části světa.
Jednou jsem nějak úplně zastavil WOT kvůli chybě s firewallem. rules_allow - to je naše pojistka proti takovým případům. Pokud jsme někde udělali chybu s firewallem, někde je něco zablokované, vždy můžeme poslat podmínku 0.0/0vše rychle vyzvednou. Později vše ručně opravíme.
Jiné sady
V prostoru můžete přidat jakékoli další sady $IPSETS$.
Proč? Občas někdo potřebuje ipset například pro emulaci vypnutí některé části clusteru. Kdokoli může přinést libovolné sady, pojmenovat je a budou vyzvednuty od konzula. Sady se přitom mohou buď účastnit pravidel iptables, nebo působit jako tým NOOP: Konzistenci bude udržovat démon.
Členové
Dříve to bylo takto: uživatel se připojil k síti a přijímal parametry přes doménu. Před příchodem nové generace firewallů Cisco nevědělo, jak porozumět tomu, kde je uživatel a kde je IP. Proto byl přístup udělen pouze prostřednictvím názvu hostitele počítače.
co jsme udělali? Zasekli jsme se ve chvíli, kdy jsme dostali adresu. Obvykle je to dot1x, Wi-Fi nebo VPN – vše jde přes RADIUS. Pro každého uživatele vytvoříme skupinu podle uživatelského jména a do ní umístíme IP s TTL, která se rovná jeho dhcp.lease - jakmile vyprší, pravidlo zmizí.
Nyní můžeme otevřít přístup ke službám, stejně jako ostatní skupiny, pomocí uživatelského jména. Zbavili jsme se bolesti z názvů hostitelů, když se změní, a zbavili jsme zátěže síťových inženýrů, protože již nepotřebují Cisco. Nyní sami inženýři registrují přístup na své servery.
Izolace
Zároveň jsme začali rozebírat izolaci. Manažeři služeb provedli inventuru a analyzovali jsme všechny naše sítě. Rozdělme je do stejných skupin a na potřebných serverech byly skupiny přidány, například pro popření. Nyní stejná inscenační izolace končí v pravidlech_popírání produkce, ale ne v produkci samotné.
Schéma funguje rychle a jednoduše: odstraníme všechny ACL ze serverů, uvolníme hardware a snížíme počet izolovaných VLAN.
Kontrola integrity
Dříve jsme měli speciální spouštěč, který hlásil, když někdo ručně změnil pravidlo brány firewall. Psal jsem obrovský linter pro kontrolu pravidel firewallu, bylo to obtížné. Integritu nyní řídí BEFW. Horlivě dbá na to, aby se pravidla, která stanoví, neměnila. Pokud někdo změní pravidla firewallu, změní to vše zpět. „Rychle jsem nastavil proxy, abych mohl pracovat z domova“ – více takových možností neexistuje.
BEFW řídí ipset ze služeb a seznam v befw.conf, pravidla služeb v řetězci BEFW. Nesleduje ale další řetězce a pravidla a další ipsety.
Ochrana proti nárazu
BEFW vždy ukládá poslední známý dobrý stav přímo do binární struktury state.bin. Pokud se něco pokazí, vždy se to vrátí zpět do tohoto stavu.bin.
Jde o pojistku proti nestabilnímu provozu Consul, kdy neodesílal data nebo se někdo spletl a použil pravidla, která nelze aplikovat. Abychom zajistili, že nezůstaneme bez firewallu, BEFW se vrátí zpět do nejnovějšího stavu, pokud v jakékoli fázi dojde k chybě.
V kritických situacích je to záruka, že nám zůstane funkční firewall. Otevíráme všechny šedé sítě v naději, že admin přijde a opraví to. Jednoho dne to vložím do konfigurací, ale teď máme jen tři šedé sítě: 10/8, 172/12 a 192.168/16. V rámci našeho konzula je to důležitá funkce, která nám pomáhá dále se rozvíjet.
Demo: během reportáže Ivan předvádí demo režim BEFW. Je snazší sledovat ukázku . Demo zdrojový kód dostupný .
Úskalí
Řeknu vám o chybách, se kterými jsme se setkali.
ipset přidat sadu 0.0.0.0/0. Co se stane, když k ipset přidáte 0.0.0.0/0? Budou přidány všechny IP adresy? Bude k dispozici internet?
Ne, dostaneme chybu, která nás bude stát dvě hodiny výpadku. Chyba navíc nefunguje od roku 2016, nachází se v RedHat Bugzilla pod číslem #1297092 a našli jsme ji náhodou – ze zprávy vývojáře.
To je nyní v BEFW přísným pravidlem 0.0.0.0/0 se změní na dvě adresy: 0.0.0.0/1 и 128.0.0.0/1.
ipset restore set < soubor. Co udělá ipset, když mu to řeknete restore? Myslíte, že to funguje stejně jako iptables? Obnoví data?
Nic takového – sloučí se a staré adresy nikam nejdou, přístup neblokujete.
Při testování izolace jsme našli chybu. Nyní existuje poměrně složitý systém - místo toho restore držený create temppak restore flush temp и restore temp. Na konci swapu: za atomicitu, protože pokud to uděláte jako první flush a v tuto chvíli dorazí nějaký paket, bude zahozen a něco se pokazí. Takže je tam trochu černé magie.
consul kv get -datacenter=other. Jak jsem řekl, myslíme si, že žádáme o nějaká data, ale buď dostaneme data, nebo chybu. Můžeme to udělat přes Consul lokálně, ale v tomto případě obojí zamrzne.
Místní klient Consul je obal přes HTTP API. Ale prostě se zasekne a nereaguje pouze na Ctrl+C, nebo Ctrl+Z nebo cokoliv jiného kill -9 v další konzoli. Setkali jsme se s tím, když jsme budovali velký cluster. Ale zatím nemáme řešení; připravujeme se na opravu této chyby v Consul.
Vedoucí konzula nereaguje. Náš mistr v datovém centru nereaguje, myslíme si: "Možná bude algoritmus opětovného výběru nyní fungovat?"
Ne, nebude to fungovat a monitorování nic neukáže: Konzul řekne, že existuje index závazků, byl nalezen vůdce, vše je v pořádku.
Jak se s tím vypořádáme? service consul restart v cronu každou hodinu. Pokud máte 50 serverů, nevadí. Až jich bude 16 000, pochopíte, jak to funguje.
Závěr
V důsledku toho jsme získali následující výhody:
- 100% pokrytí všech linuxových strojů.
- Rychlost.
- Automatizace.
- Osvobodili jsme hardwarové a síťové inženýry z otroctví.
- Objevily se možnosti integrace, které jsou téměř neomezené: dokonce i s Kubernetes, dokonce i s Ansible, dokonce i s Pythonem.
Zápory: Konzul, se kterým nyní musíme žít, a velmi vysoké náklady na chyby. Jako příklad jsem jednou v 6 hodin (hlavní vysílací čas v Rusku) něco upravoval v seznamech sítí. V BEFW jsme tehdy zrovna stavěli izolaci. Někde jsem udělal chybu, zdá se, že jsem naznačil špatnou masku, ale vše padlo do dvou sekund. Monitorování se rozsvítí, přiběhne pomocná osoba: "Máme všechno!" Vedoucí oddělení zešedivěl, když podniku vysvětlil, proč se tak stalo.
Cena chyby je tak vysoká, že jsme přišli s vlastním komplexním preventivním postupem. Pokud to implementujete na velkém produkčním webu, nemusíte všem dávat hlavní token nad Consul. Tohle skončí špatně.
Náklady. Jen jsem psal kód 400 hodin. Můj tým 4 lidí tráví 10 hodin měsíčně podporou pro každého. V porovnání s cenou jakéhokoli firewallu nové generace je to zdarma.
Plány. Dlouhodobým plánem je najít alternativní dopravu, která by nahradila nebo doplnila konzula. Možná to bude Kafka nebo něco podobného. Ale v příštích letech budeme žít na Consul.
Okamžité plány: integrace s Fail2ban, s monitoringem, s nftables, případně s dalšími distribucemi, metriky, pokročilý monitoring, optimalizace. Podpora Kubernetes je také někde v plánu, protože nyní máme několik clusterů a přání.
Více z plánů:
- hledat anomálie v dopravě;
- Správa síťových map;
- podpora Kubernetes;
- sestavování balíčků pro všechny systémy;
- Webové uživatelské rozhraní.
Neustále pracujeme na rozšiřování konfigurace, zvyšování metrik a optimalizaci.
Připojte se k projektu. Projekt se ukázal jako skvělý, ale bohužel je to stále projekt jednoho člověka. Přijď k a pokuste se něco udělat: zavázat se, otestovat, něco navrhnout, vyjádřit svůj názor.
Mezitím se připravujeme na , který se bude konat 6. a 7. dubna v Petrohradě a zveme vývojáře vysokozátěžových systémů . Zkušení řečníci již vědí, co mají dělat, ale pro ty, kteří s mluvením začínají, doporučujeme alespoň . Účast na konferenci jako řečník má řadu výhod. Které to jsou, si můžete přečíst třeba na konci .
Zdroj: www.habr.com
