Nel 2010 l'azienda aveva 50 server e un modello di rete semplice: backend, frontend e firewall. Il numero di server cresceva, il modello si complicava: staging, VLAN isolate con ACL, poi VPN con VRF, VLAN con ACL su L2, VRF con ACL su L3. Ti gira la testa? Andrà ancora meglio.
Quando il numero di server è arrivato a 16.000, lavorare senza lacrime con una tale quantità di segmenti eterogenei è diventato impossibile. Pertanto, hanno trovato un'altra soluzione. Hanno preso il stack Netfilter, aggiunto Consul come fonte di dati, e hanno ottenuto un firewall distribuito e veloce. Hanno sostituito le ACL sui router e lo hanno utilizzato come firewall esterno e interno. Per la gestione dinamica dello strumento, hanno sviluppato il sistema BEFW, applicato ovunque: dalla gestione dell'accesso degli utenti nella rete di produzione all'isolamento dei segmenti di rete l'uno dall'altro.
Come funziona tutto ciò e perché dovreste prestare attenzione a questo sistema, sarà spiegato da Ivan Agar'kov () — responsabile del gruppo di sicurezza infrastrutturale del dipartimento Maintenance presso il centro di sviluppo di Minsk dell'azienda. Ivan è un fan di SELinux, ama Perl e scrive codice. Come responsabile del gruppo di sicurezza informatica, lavora regolarmente con i log, i backup e R&D per proteggere Wargaming dagli hacker e garantire il funzionamento di tutti i server di gioco dell'azienda.
Nota storica
Prima di spiegare come abbiamo fatto, voglio raccontare come siamo arrivati a questa situazione e perché è stato necessario. Torniamo indietro di 9 anni: 2010, è appena uscito World of Tanks. Wargaming aveva circa 50 server.
Grafico della crescita dei server dell'azienda.
Avevamo un modello di rete. Per quell'epoca era ottimale.
Modello di rete nel 2010.
Nel frontend ci sono i cattivi che vogliono romperci, ma c'è un firewall. Nel backend non c'è firewall, ma ci sono 50 server, li conosciamo tutti. Tutto funziona bene.
In 4 anni, il parco server è cresciuto di 100 volte, raggiungendo i 5000. Sono emerse le prime reti isolate: gli staging: non possono andare in produzione, e spesso era in esecuzione ciò che poteva essere pericoloso.
Modello di rete nel 2014.
Per inerzia abbiamo usato gli stessi hardware e tutto il lavoro si svolgeva su VLAN isolate: sulle VLAN sono scritte le ACL che autorizzano o impediscono una certa connessione.
Nel 2016 il numero dei server ha raggiunto 8000. Wargaming ha acquisito altri studi, sono emerse ulteriori reti partner. Sembrano essere nostri, ma non del tutto: per i partner, VLAN funzionano spesso male, è necessario utilizzare VPN con VRF, le isolazioni si complicano. La miscela di isolamenti ACL è aumentata.
Modello di rete nel 2016.
All'inizio del 2018 il parco macchine è cresciuto fino a 16.000. C'erano 6 segmenti e gli altri non li contavamo, compresi quelli chiusi, in cui erano conservati dati finanziari. Sono emerse reti containerizzate (Kubernetes), DevOps, reti cloud collegate tramite VPN, ad esempio, da ISV. C'erano troppe regole — era doloroso.
Modello di rete e metodi di isolamento nel 2018.
Per l'isolamento abbiamo utilizzato: VLAN con ACL su L2, VRF con ACL su L3, VPN e molto altro. Troppo.
Problemi
Tutti vivono con ACL e VLAN. Cosa c'è che non va? A questa domanda risponderà Harold, nascondendo il dolore.
Ci sono stati molti problemi, ma quelli di massa sono stati cinque.
- Aumento geometrico del prezzo per nuove regole. Ogni nuova regola impiegava più tempo per essere aggiunta rispetto alla precedente, perché dovevamo prima vedere se esisteva già una regola simile.
- Nessun firewall all'interno dei segmenti. I segmenti sono stati in qualche modo separati tra loro, all'interno non ci sono risorse sufficienti.
- Le regole venivano applicate lentamente. A mano, un operatore poteva scrivere una regola locale in un'ora. Una globale richiedeva diversi giorni.
- Difficoltà con l'audit delle regole. A dire il vero, non era possibile. Le prime regole sono state scritte nel 2010 e gran parte dei loro autori non lavorava più in azienda.
- Basso livello di controllo sull'infrastruttura. Questo è il problema principale: non sapevamo cosa stesse succedendo.
Ecco come appariva un ingegnere di rete nel 2018 quando sentiva: «Serve ancora un po' di ACL».
Soluzioni
All'inizio del 2018 è stato deciso di fare qualcosa al riguardo.
Il costo delle integrazioni cresce continuamente. Il punto di partenza è stato che i grandi data center hanno smesso di supportare VLAN e ACL isolati perché la memoria sui dispositivi era esaurita.
Soluzione: eliminato il fattore umano e massimizzato l'automazione della concessione degli accessi.
Le nuove regole vengono applicate lentamente. Soluzione: accelerare l'applicazione delle regole, renderla distribuita e parallela. È necessaria una rete distribuita affinché le regole vengano applicate automaticamente, senza rsync o SFTP su mille sistemi.
Assenza di firewall all'interno dei segmenti. Il firewall all'interno dei segmenti ha iniziato a influenzarci quando diversi servizi sono emersi all'interno della rete. Soluzione: utilizzare un firewall a livello host — firewalls basati su host. Praticamente ovunque abbiamo Linux e ovunque ci sono iptables, quindi non è un problema.
Difficoltà con l'audit delle regole. Soluzione: conservare tutte le regole in un'unica posizione per una visione e una gestione migliori, così potremo auditarle tutte.
Basso livello di controllo sull'infrastruttura. Soluzione: effettuare un'inventario di tutti i servizi e degli accessi tra di essi.
Questo è più un processo amministrativo che tecnico. A volte abbiamo 200-300 nuove release a settimana, specialmente durante le promozioni e le festività. Questo è solo per un team dei nostri DevOps. Con un numero così elevato di release è impossibile definire quali porte, IP e integrazioni siano necessari. Pertanto, abbiamo avuto bisogno di manager di servizio specificamente formati, che interrogassero i team: 'Cosa esiste realmente e perché lo avete lanciato?'
Dopo tutto ciò che abbiamo avviato, nel 2019 l'ingegnere di rete era già così.
Consul
Abbiamo deciso di inserire tutto ciò che abbiamo trovato tramite i manager di servizio in Consul e da lì scriveremo le regole di iptables.
Come abbiamo deciso di procedere?
- Raccoglieremo tutti i servizi, le reti e gli utenti.
- Creeremo regole iptables basate su di essi.
- Automatizzeremo il controllo.
- ….
- PROFIT.
Consul non è un'API remota, può funzionare su ogni nodo e scrivere in iptables. Rimane solo da inventare strumenti di controllo automatico che puliranno il superfluo, e la maggior parte dei problemi sarà risolta! Il resto verrà completato durante il processo.
Perché Consul?
Si è dimostrato efficace. Nel 2014-15 lo abbiamo utilizzato come backend per Vault, dove conserviamo le password.
Non perde dati.Durante l'uso, Consul non ha mai perso dati in nessun incidente. Questo è un grande vantaggio per il sistema di gestione del firewall.
Le connessioni P2P accelerano la diffusione delle modifiche.Con P2P tutte le modifiche arrivano rapidamente, non bisogna aspettare per ore.
API REST conveniente. Abbiamo considerato anche Apache ZooKeeper, ma non ha un'API REST, quindi dovremo trovare soluzioni alternative.
Funciona sia come un deposito di chiavi (KV) che come un catalogo (Service Discovery).È possibile conservare servizi, cataloghi e data center simultaneamente. Questo è utile non solo per noi, ma anche per i team vicini, poiché costruendo un servizio globale, pensiamo in grande.
Scritto in Go, che fa parte dello stack di Wargaming. Amiamo questa lingua, abbiamo molti sviluppatori Go.
Un potente sistema ACL. In Consul, grazie all'ACL, puoi gestire chi può scrivere e cosa. Garantiamo che le regole del firewall non entreranno in conflitto e non avremo problemi con questo.
Ma Consul ha anche delle limitazioni.
- Non si scala all'interno del data center, a meno che tu non abbia la versione business. Si scala solo attraverso la federazione.
- È molto dipendente dalla qualità della rete e dal carico dei server. Consul non funzionerà correttamente come server su un server sovraccarico, se ci sono dei lag in rete, per esempio, velocità irregolare. Questo è legato alle connessioni P2P e ai modelli di distribuzione degli aggiornamenti.
- Difficoltà nel monitorare la disponibilità. Nel rapporto di stato, Consul può dire che va tutto bene, mentre in realtà è già morto da tempo.
La maggior parte di questi problemi sono stati risolti durante l'uso di Consul, per questo motivo siamo stati costretti a sceglierlo. Ci sono piani per un backend alternativo, ma abbiamo imparato a gestire i problemi e per ora conviviamo con Consul.
Come funziona Consul
Nel nostro data center ipotetico installeremo server — da tre a cinque. Uno o due server non andranno bene: non riusciranno a organizzare un quorum e decidere chi ha ragione e chi ha torto quando i dati non corrispondono. Più di cinque non ha senso, la performance calerà.
I client si connettono ai server in qualsiasi ordine: gli stessi agenti, ma con il flag server = false.
Dopo di che, i client ricevono un elenco di connessioni P2P e stabiliscono connessioni tra di loro.
A livello globale, colleghiamo più data center. Anche loro si connettono in P2P e comunicano.
Quando vogliamo prelevare dati da un altro data center, la richiesta passa da server a server. Questo schema si chiama protocollo Serf. Il protocollo Serf, come Consul, è una creazione di HashiCorp.
Alcuni fatti importanti su Consul
Consul ha una documentazione che ne descrive il funzionamento. Riporterò solo alcuni fatti selettivi che è opportuno conoscere.
I server Consul scelgono un master tra i votanti. Consul sceglie un master dalla lista di server per ogni data center, e tutte le richieste vanno solo a lui, indipendentemente dal numero di server. Il blocco del master non porta a nuove elezioni. Se non viene scelto un master, le richieste non vengono servite.
Volevi scalabilità orizzontale? Ci dispiace, no.
La richiesta in un altro data center va da master a master, indipendentemente dal server su cui è arrivata. Il master selezionato riceve il 100% del carico, eccetto il carico sulla richiesta di inoltro. Ogni server del data center ha una copia attuale dei dati, ma solo uno risponde.
L'unico modo per scalare è attivare la modalità stale sul client.
In modalità stale si può rispondere senza quorum. Questo è un modo in cui rinunciamo alla coerenza dei dati, ma leggiamo un po' più velocemente del normale e risponde qualsiasi server. Naturalmente, le scritture sono solo attraverso il master.
Consul non copia i dati tra i data center.Durante la federazione ogni server avrà solo i propri dati. Per gli altri si rivolgerà sempre a qualcun altro.
L'atomicità delle operazioni non è garantita al di fuori della transazione.Ricorda che a modificare qualcosa non sei solo tu. Se vuoi farlo in modo diverso, esegui una transazione con blocco.
Le operazioni bloccanti non garantiscono il blocco.La richiesta va da master a master e non direttamente, quindi non ci sono garanzie che il blocco funzioni quando lo instauri, ad esempio in un altro data center.
Anche l'ACL non garantisce l'accesso (in molti casi).L'ACL potrebbe non funzionare perché è memorizzato in un solo data center della federazione — nel data center ACL (Primary DC). Se il DC non risponde, l'ACL non funzionerà.
Un master bloccato porterà al blocco dell'intera federazione.Ad esempio, in una federazione di 10 data center, se uno ha una connessione scadente e un master si blocca, tutti coloro che comunicano con esso si bloccheranno in un ciclo: c'è una richiesta, non c'è risposta, il thread si blocca. Non sarà possibile sapere quando accadrà; semplicemente dopo un'ora o due tutta la federazione si bloccherà. Non potrai farci nulla.
Lo stato, il quorum e le elezioni vengono gestiti da un thread separato. Non ci saranno rieleggibilità, lo stato non mostrerà nulla. Pensate di avere un Consul attivo, lo interrogate e non succede nulla: non c'è risposta. Eppure lo stato mostra che tutto va bene.
Ci siamo imbattuti in questo problema, ci è toccato ricostruire parti specifiche dei data center per evitarlo.
Nella versione aziendale di Consul Enterprise non ci sono alcuni difetti sopra citati.. Ci sono molte funzionalità utili: selezione dei votanti, distribuzione, scalabilità. C'è solo un «ma»: il sistema di licensing per il sistema distribuito è molto costoso.
Trick: rm -rf /var/lib/consul — la medicina per tutti i mali dell'agente. Se qualcosa non funziona, basta eliminare i propri dati e caricare i dati da una copia. Probabilmente Consul riprenderà a funzionare.
BEFW
Ora parliamo di ciò che abbiamo aggiunto a Consul.
— è un acronimo di BackEndFireWall. Dovevo trovare un nome per il prodotto quando ho creato il repository, per inserirvi i primi commit di test. Questo nome è rimasto.
Template delle regole
Le regole sono scritte nella sintassi di iptables.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m state—state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Tutto passa attraverso la catena BEFW, tranne ESTABLISHED, RELATED e localhost. Il template può essere qualsiasi, è solo un esempio.
Qual è l'utilità di BEFW?
Servizi
Abbiamo un servizio, ha sempre una porta, un nodo su cui funziona. Dallo stesso nodo possiamo localmente chiedere all'agente e scoprire che abbiamo un certo servizio. Possono anche essere assegnati tag.
Qualsiasi servizio avviato e registrato in Consul si trasforma in una regola di iptables. Abbiamo SSH — apriamo la porta 22. Lo script Bash è semplice: curl e iptables, non serve altro.
Clienti
Come permettere l'accesso non a tutti, ma selettivamente? Aggiungere elenchi di IP nel KV-storage per nome del servizio.
Ad esempio, vogliamo che tutti dalla decima rete possano accedere al servizio SSH_TCP_22. Aggiungiamo un piccolo campo TTL? e ora abbiamo permessi temporanei, ad esempio per un giorno.
Accessi
Colleghiamo servizi e clienti: abbiamo un servizio, per ogni servizio è pronta una KV-storage. Ora diamo accesso non a tutti, ma selettivamente.
Gruppi
Se ogni volta dobbiamo scrivere migliaia di IP per gli accessi, ci stancheremo. Creiamo delle raggruppamenti: un sottoinsieme separato nel KV. Lo chiameremo Alias (o gruppi) e vi conserveremo i gruppi secondo lo stesso principio.
Colleghiamo: ora possiamo aprire SSH non specificamente su P2P, ma su un intero gruppo o più gruppi. Anche in questo caso c'è TTL — si possono aggiungere e rimuovere dai gruppi temporaneamente.
Integrazione
Il nostro problema è il fattore umano e l'automazione. Finora l'abbiamo risolto in questo modo.
Lavoriamo con Puppet e trasferiamo a lui tutto ciò che riguarda il sistema (codice delle applicazioni). In puppetdb (un comune PostgreSQL) è memorizzato un elenco dei servizi in esecuzione, che possono essere trovati in base al tipo di risorsa. Lì possiamo anche vedere chi richiede cosa. Abbiamo anche un sistema di pull request e merge request per questo.
Abbiamo scritto befw-sync — una soluzione semplice che aiuta a trasferire dati. Innanzitutto, gli sync cookies fanno riferimento a puppetdb. Lì è configurato un HTTP API: chiediamo quali servizi abbiamo e cosa deve essere fatto. Poi viene effettuata una richiesta a Consul.
C'è integrazione? Sì: abbiamo scritto delle regole, consentito di accettare Pull Request. Serve una porta o aggiungere un host a un gruppo? Pull Request, revisione — nulla di più 'Trova 200 altri ACL e prova a fare qualcosa con essi'.
Ottimizzazione
Il ping a localhost con una catena di regole vuota impiega 0,075 ms.
Aggiungiamo a questa catena 10.000 indirizzi iptables. Di conseguenza, il ping aumenta di 5 volte: iptables è completamente lineare, il trattamento di ogni indirizzo richiede un certo tempo.
Per il firewall in cui migreremo migliaia di ACL, abbiamo molte regole, e questo introduce ritardi. Questo è negativo per i protocolli di gioco.
Ma se inseriamo 10.000 indirizzi in ipset il ping diminuirà persino.
Il punto è che "O" (complessità dell'algoritmo) per ipset è sempre uguale a 1, indipendentemente da quante regole ci siano. In realtà, c'è un limite: non può esserci più di 65535 regole. Fino ad ora ci conviviamo: possiamo combinarle, espandere, fare due ipset in uno.
Archiviazione
Un'estensione logica del processo di iterazione è la memorizzazione delle informazioni sui clienti per il servizio in ipset.
Ora abbiamo lo stesso SSH e non scriviamo immediatamente 100 IP, ma definiamo il nome dell'ipset con cui dobbiamo interagire e la seguente regola DROP. Possiamo riformulare in un'unica regola 'Chi non è qui, viene bloccato', ma così è più chiaro.
Ora abbiamo regole e set. L'obiettivo principale è creare il set prima di scrivere la regola, perché altrimenti iptables non registrerà la regola.
Schema generale
In forma schematica, tutto ciò che ho raccontato sembra così.
Effettuiamo il commit in Puppet, tutto viene inviato all'host, i servizi qui, ipset lì, e chi non è registrato lì non è autorizzato ad accedere.
Allow & deny
Per salvare rapidamente il mondo o disconnettere qualcuno repentinamente, all'inizio di tutte le catene abbiamo creato due ipset: rules_allow e rules_deny. Come funziona?
Ad esempio, qualcuno crea un carico sul nostro Web con bot. In passato era necessario trovare il suo IP nei log, portarlo agli ingegneri di rete affinchè trovassero la sorgente del traffico e la bloccassero. Ora è diverso.
Invio a Consul, aspetto 2,5 secondi, ed è fatto. Poiché Consul distribuisce rapidamente grazie al P2P, funziona ovunque, in qualsiasi parte del mondo.
Una volta ho completamente bloccato WOT, commettendo un errore con il firewall. rules_allow — questa è la nostra assicurazione contro tali casi. Se abbiamo commesso un errore con il firewall e qualcosa viene bloccato, possiamo sempre inviare un 0.0/0, per ripristinare tutto velocemente. Poi sistemeremo tutto manualmente.
Altri set
È possibile aggiungere altri set nello spazio $IPSETS$.
Perché? A volte qualcuno ha bisogno di ipset, ad esempio per emulare la disattivazione di una parte del cluster. Ognuno può portare qualsiasi set, chiamarlo e saranno recuperati da Consul. Inoltre, i set possono partecipare alle regole iptables o funzionare come un comando NOOP: la coerenza sarà mantenuta dal demone.
Utenti
Una volta era così: l'utente si collegava alla rete e riceveva parametri tramite un dominio. Fino all'arrivo dei firewall di nuova generazione, Cisco non sapeva dove si trovasse l'utente e dove fosse l'IP. Pertanto, l'accesso veniva fornito solo tramite il nome host della macchina.
Cosa abbiamo fatto noi? Ci siamo inseriti nel momento in cui si riceve l'indirizzo. Di solito si tratta di dot1x, Wi-Fi o VPN, tutto passa attraverso RADIUS. Creiamo un gruppo per ogni utente con il nome utente e ci mettiamo l'IP con TTL, che è uguale al suo dhcp.lease: non appena scade, la regola scompare.
Ora possiamo aprire l'accesso ai servizi, come negli altri gruppi, in base al nome utente. Ci siamo liberati del problema del nome host, quando questi cambiano, e abbiamo alleggerito il carico sugli ingegneri di rete, poiché non hanno più bisogno di Cisco. Ora gli ingegneri stesso configurano gli accessi sui loro server.
Isolamento
Parallelamente, abbiamo iniziato a esaminare l'isolamento. I manager dei servizi hanno effettuato un inventario e noi abbiamo analizzato tutte le nostre reti. Le organizziamo in gruppi simili e sui server necessari abbiamo aggiunto i gruppi, ad esempio, in deny. Ora la stessa isolamento del staging finisce nelle rules_deny della produzione, ma non nella produzione stessa.
Lo schema funziona in modo veloce e semplice: rimuoviamo tutte le ACL dai server, alleviamo il carico dell'hardware e riduciamo il numero di VLAN isolate.
Controllo dell'integrità
In passato avevamo un trigger speciale che avvisava quando qualcuno cambiava manualmente una regola del firewall. Ho scritto un enorme linter per il controllo delle regole del firewall, è stato complicato. Ora l'integrità è controllata da BEFW. Esso segue attentamente affinché le regole che crea non vengano modificate. Se qualcuno cambia le regole del firewall, ritorna tutto indietro. "Ho rapidamente avviato un proxy per lavorare da casa" — non ci sono più queste opzioni.
BEFW controlla ipset dei servizi e dell'elenco in befw.conf, le regole dei servizi nella catena BEFW. Ma non controlla altre catene e regole e altri ipset.
Protezione da guasti
BEFW salva sempre l'ultimo stato positivo direttamente nella struttura binaria state.bin. Se qualcosa va storto, torna sempre a questo state.bin.
Questa è un'assicurazione contro il funzionamento instabile di Consul, quando non invia dati o qualcuno ha commesso un errore utilizzando regole che non sono applicabili. Così, per non rimanere senza firewall, BEFW tornerà all'ultimo stato se si verifica un errore in qualche fase.
In situazioni critiche, questa è una garanzia che rimarremo con un firewall funzionante. Apriamo tutte le reti grigie nella speranza che l'amministratore venga e ripari. Prima o poi porterò queste informazioni nei config, ma ora abbiamo semplicemente tre reti grigie: 10/8, 172/12 e 192.168/16. Nell'ambito del nostro Consul, questa è una caratteristica importante che aiuta a progredire ulteriormente.
Demo: durante la relazione Ivan dimostra la modalità demo di funzionamento di BEFW. È più comodo guardare la dimostrazione su . Il codice sorgente della demo è disponibile .
Inconvenienti
Parlerò dei bug con cui abbiamo avuto a che fare.
ipset add set 0.0.0.0/0. Cosa succede se si aggiunge a ipset 0.0.0.0/0? Aggiunge tutti gli IP? Si apre l'accesso a Internet?
No, otteniamo un bug che ci è costato due ore di inattività. Inoltre, il bug non funziona dal 2016, è registrato in RedHat Bugzilla con il numero #1297092, e lo abbiamo trovato per caso — dal rapporto dello sviluppatore.
Ora in BEFW c'è una regola rigida, che 0.0.0.0/0 si trasforma in due indirizzi: 0.0.0.0/1 e 128.0.0.0/1.
ipset restore set < file. Cosa fa ipset quando gli dici restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Niente affatto — fa un merge, e i vecchi indirizzi non scompaiono, non chiudi l'accesso.
Abbiamo trovato il bug quando testavamo l'isolamento. Ora lì c'è un sistema piuttosto complesso — invece di restore si svolge create temp, poi restore flush temp e restore temp. Alla fine swap: per atomicità, perché se si fa prima flush e in quel momento arriverà qualche pacchetto, esso sarà scartato e qualcosa andrà storto. Quindi c'è un po' di magia nera.
consul kv get -datacenter=other. Come ho già detto, pensiamo di richiedere alcuni dati, ma riceveremo o i dati o un errore. Possiamo farlo tramite Consul localmente, ma in questo caso si bloccherà sia quello che l'altro.
Il client Consul locale è un involucro sopra l'API HTTP. Ma si blocca semplicemente e non risponde né a Ctrl+C, né a Ctrl+Z, né a nulla, solo a kill -9 nella console vicina. Abbiamo riscontrato questo quando stavamo costruendo un grande cluster. Ma per ora non abbiamo soluzioni, ci stiamo preparando a correggere questo errore in Consul.
Il leader di Consul non risponde. Il nostro master nel data center non risponde, pensiamo: «Probabilmente sta per attivarsi l'algoritmo di ripristino?»
No, non succederà e il monitoraggio non mostrerà nulla: Consul dirà che c'è un commitment index, che il leader è stato trovato, tutto bene.
Come facciamo a combattere questo? service consul restart in cron ogni ora. Se hai 50 server, non è grave. Quando ne avrai 16.000, capirai come funziona.
Conclusione
Alla fine abbiamo ottenuto i seguenti vantaggi:
- copertura del 100% di tutte le macchine Linux.
- Velocità.
- Automazione.
- Abbiamo liberato l'hardware e gli ingegneri di rete dalla schiavitù.
- Sono emerse possibilità di integrazione che sono praticamente illimitate: con Kubernetes, con Ansible, con Python.
Contro: Consul, con cui ora dobbiamo convivere, e il prezzo dell'errore è molto alto. Come esempio, una volta ho modificato alcuni elenchi di reti alle 6 di sera (ora di punta in Russia). Proprio in quel momento stavamo costruendo l'isolamento su BEFW. Ho fatto qualche errore, credo di aver specificato la maschera errata, ma tutto è crollato in due secondi. Si accende il monitoraggio, il tecnico del supporto corre: «Tutto è giù!» Il capo dipartimento è diventato grigio mentre spiegava al business perché era successo.
Il prezzo dell'errore è così alto che abbiamo ideato una complessa procedura preventiva. Se stai implementando questa cosa in una grande produzione, non dare il master-token su Consul a chiunque. Finirà male.
Costo. Ho scritto codice per 400 ore da solo. La mia squadra di 4 persone spende 10 ore al mese per il supporto a tutti. Rispetto al costo di qualsiasi firewall di nuova generazione, è gratis.
Piani. Il piano a lungo termine è cercare un trasporto alternativo in sostituzione o in aggiunta a Consul. Potrebbe essere Kafka o qualcosa di simile. Ma nei prossimi anni vivremo con Consul.
Piani più prossimi: integrazione con Fail2ban, monitoraggio, nftables, forse con altri sistemi operativi, metriche, monitoraggio avanzato, ottimizzazione. Il supporto per Kubernetes è anche in programma, poiché attualmente abbiamo diversi cluster e la volontà.
Altri piani:
- ricerca di anomalie nel traffico;
- gestione della mappa di rete;
- supporto per Kubernetes;
- compilazione di pacchetti per tutti i sistemi;
- Web-UI.
Lavoriamo costantemente per espandere la configurazione, aumentare le metriche e ottimizzare.
Unisciti al progetto. Il progetto è fantastico, ma, sfortunatamente, è ancora un progetto di una sola persona. Vieni su e prova a fare qualcosa: commit, testare, fare una proposta, dare il tuo feedback.
Nel frattempo, ci stiamo preparando per , che si terrà il 6 e 7 aprile a San Pietroburgo, e invitiamo gli sviluppatori di sistemi ad alta intensità di carico . I relatori esperti sanno già cosa fare, ma ai principianti nei loro interventi raccomandiamo almeno di . Partecipare alla conferenza come relatore ha diversi vantaggi. Di quali vantaggi, puoi leggere, per esempio, alla fine .
Fonte: habr.com
