Nel 2010, l'azienda aveva 50 server e un semplice modello di rete: backend, frontend e firewall. Il numero di server è aumentato, il modello si è fatto più complesso: stage, VLAN isolate con ACL, poi VPN con VRF, VLAN con ACL su L2, VRF con ACL su L3. Ti sei già confuso? Proseguiamo, sarà ancora più interessante.
Quando il numero di server è salito a 16.000, lavorare senza problemi con così tanti segmenti diversi è diventato impossibile. Così hanno pensato a una soluzione alternativa. Hanno preso il stack Netfilter e gli hanno aggiunto Consul come sorgente di dati, creando un firewall distribuito veloce. Hanno sostituito le ACL sui router e lo hanno utilizzato come firewall esterno e interno. Per gestire dinamicamente lo strumento, hanno sviluppato un sistema chiamato BEFW, utilizzato ovunque: dalla gestione degli accessi degli utenti alla rete di produzione fino all'isolamento dei segmenti di rete tra di loro.
Come funziona tutto questo e perché dovresti considerare seriamente questo sistema verrà spiegato da Ivan Agarov () — responsabile del gruppo di infrastruttura di sicurezza della divisione Maintenance presso il centro di sviluppo di Minsk dell'azienda. Ivan è un appassionato di SELinux, ama Perl e scrive codice. In qualità di responsabile del gruppo di sicurezza informatica, lavora regolarmente con i log, i backup e la Ricerca e Sviluppo per proteggere Wargaming dagli hacker e garantire il funzionamento di tutti i server di gioco dell'azienda.
Nota storica
Prima di parlare di come lo abbiamo fatto, spiegherò come siamo arrivati a questo punto e perché fosse necessario. Torniamo indietro di 9 anni: nel 2010, quando sono stati lanciati i World of Tanks. Wargaming aveva circa 50 server.
Grafico della crescita dei server dell'azienda.
Avevamo un modello di rete. All'epoca era ottimale.
Modello di rete nel 2010.
Sulla parte frontale ci sono i cattivi che vogliono romperci, ma c'è un firewall. Sul retro non c'è firewall, ma ci sono 50 server, e li conosciamo tutti. Tutto funziona bene.
In 4 anni, il parco server è cresciuto di 100 volte, fino a 5000. Sono emerse le prime reti isolate — st stage: non possono accedere alla produzione, e lì giravano spesso things che potevano essere pericolosi.
Modello di rete nel 2014.
Per inerzia, abbiamo utilizzato gli stessi hardware, e tutto il lavoro si svolgeva su VLAN isolate: le ACL vengono scritte per le VLAN, che autorizzano o bloccano alcune connessioni.
Nel 2016, il numero di server ha raggiunto quota 8000. Wargaming ha acquisito altri studi, sono emerse reti partner aggiuntive. Sembrano essere nostri, ma non del tutto: per i partner, le VLAN spesso non funzionano, costringendo all'uso di VPN con VRF, e le isolazioni si complicano. La mescolanza di isolamenti ACL è aumentata.
Modello di rete nel 2016.
All'inizio del 2018, il parco macchine è cresciuto fino a 16.000. I segmenti erano 6, mentre gli altri non li consideravamo, inclusi quelli chiusi, in cui erano conservati dati finanziari. Sono emerse reti containeriche (Kubernetes), DevOps, reti cloud collegate tramite VPN, ad esempio, da IWS. Le regole erano moltissime — era un vero problema.
Modello di rete e modi di isolamento nel 2018.
Per l'isolamento utilizzavamo: VLAN con ACL a L2, VRF con ACL a L3, VPN e molto altro. Troppo.
Problemi
Tutti vivono con ACL e VLAN. Qual è il problema? Questa domanda sarà risposta da Harold, nascondendo il dolore.
Ci sono stati molti problemi, ma di massa — cinque.
- Crescita geometrica dei prezzi per le nuove regole.. Ogni nuova regola veniva aggiunta più lentamente della precedente, perché dovevamo prima controllare che non ci fosse già una regola simile.
- Non c'è firewall all'interno dei segmenti. I segmenti si sono separati in qualche modo, ma all'interno già non ci sono risorse sufficienti.
- Le regole venivano applicate lentamente. A mano, un operatore poteva scrivere una regola locale in un'ora. Una regola globale richiedeva diversi giorni.
- Difficoltà con l'audit delle regole. Più precisamente, non era possibile. Le prime regole erano state scritte nel 2010 e la maggior parte dei loro autori non lavorava più in azienda.
- Basso livello di controllo sull'infrastruttura. Questo è il problema principale: non sapevamo affatto cosa stesse accadendo.
Ecco come appariva un ingegnere di rete nel 2018, quando sentiva: «Servono ancora un po' di ACL».
Soluzioni
All'inizio del 2018 si decise 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 isolate e ACL, perché la memoria sui dispositivi si era esaurita.
Soluzione: abbiamo eliminato il fattore umano e automatizzato il massimo possibile la concessione di accesso.
Le nuove regole vengono applicate lentamente. Soluzione: accelerare l'applicazione delle regole, rendendola distribuita e parallela. È necessaria una sistemazione distribuita affinché le regole vengano consegnate automaticamente, senza rsync o SFTP su mille sistemi.
Assenza di firewall all'interno dei segmenti. Il firewall interno è diventato un problema quando sono emersi diversi servizi all'interno della stessa rete. Soluzione: utilizzare un firewall a livello di host — firewall basati su host. Ovunque abbiamo Linux, e ovunque ci sono iptables, non è un problema.
Difficoltà nell'audit delle regole. Soluzione: conservare tutte le regole in un'unica posizione per revisione e gestione, così possiamo effettuare un audit completo.
Basso livello di controllo dell'infrastruttura. Soluzione: effettuare un inventario di tutti i servizi e degli accessi tra di essi.
Si tratta di un processo più amministrativo che tecnico. A volte abbiamo 200-300 nuove versioni a settimana, specialmente durante le promozioni e le festività. Questo vale solo per un team dei nostri DevOps. Con un numero così elevato di rilasci, è impossibile capire quali porte, IP e integrazioni siano necessari. Per questo motivo, abbiamo avuto bisogno di manager di servizio appositamente formati che chiedessero ai team: «Cosa avete e perché l'avete implementato?»
Dopo tutto ciò che abbiamo lanciato, nel 2019 l'ingegnere di rete appariva così.
Consul
Abbiamo deciso di inserire tutto ciò che abbiamo trovato con l'aiuto dei manager di servizio in Consul e di scrivere da lì le regole per iptables.
Come abbiamo deciso di procedere?
- Raccoglieremo tutti i servizi, le reti e gli utenti.
- Creeremo regole per 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 ideare strumenti automatici di controllo che rimuovano il superfluo, e la maggior parte dei problemi sarà risolta! Il resto lo perfezioneremo nel processo.
Perché Consul?
Si è dimostrato molto 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 caso di incidenti. Questo è un enorme vantaggio per il sistema di gestione del firewall.
Le connessioni P2P accelerano la diffusione delle modifiche. Con P2P, tutte le modifiche arrivano rapidamente, non è necessario aspettare per ore.
Un comodo REST API. Abbiamo considerato anche Apache ZooKeeper, ma non ha REST API, dovremmo utilizzare soluzioni di emergenza.
Funziona sia come archivio chiavi (KV) che come catalogo (Service Discovery). Può memorizzare servizi, cataloghi e data center contemporaneamente. 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 del stack Wargaming. Ci piace questo linguaggio, abbiamo molti sviluppatori Go.
Un potente sistema di ACL. In Consul, tramite ACL, è possibile gestire chi può scrivere e cosa. Garantiamo che le regole del firewall non si sovrapporranno a nulla e non avremo problemi a riguardo.
Ma Consul ha anche dei difetti.
- Non si scala all'interno del data center, se non si possiede la versione business. Si scala solo tramite 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 lag nella rete, ad esempio, una velocità irregolare. Questo è legato alle connessioni P2P e ai modelli di distribuzione degli aggiornamenti.
- Difficoltà nel monitoraggio della disponibilità. Nel suo stato, Consul può indicare che tutto va bene, mentre in realtà è già morto.
La maggior parte di questi problemi è stata risolta durante l'uso di Consul, ed è per questo che lo abbiamo scelto. L'azienda ha piani per un backend alternativo, ma abbiamo imparato a gestire i problemi e al momento viviamo con Consul.
Come funziona Consul
Installemo server nel data center — da tre a cinque. Uno o due server non sono sufficienti: non saranno in grado di organizzare un quorum e decidere chi ha ragione e chi ha torto quando i dati non coincidono. Più di cinque non ha senso, le prestazioni diminuiranno.
I clienti si collegano ai server in qualsiasi ordine: gli stessi agenti, ma con il flag server = false.
Dopo di ciò, i clienti ricevono un elenco di connessioni P2P e stabiliscono relazioni tra di loro.
A livello globale, colleghiamo diversi data center tra loro. Anche questi si connettono P2P e comunicano.
Quando vogliamo prelevare dati da un altro data center, la richiesta va da server a server. Questo schema è chiamato protocollo Serf. Il protocollo Serf, come Consul, è sviluppato da HashiCorp.
Alcuni fatti importanti su Consul
Consul ha una documentazione che descrive il suo funzionamento. Riporterò solo alcuni fatti selezionati che vale la pena conoscere.
I server Consul scelgono un maestro tra i votanti. Consul seleziona un maestro dalla lista dei server per ogni data center, e tutte le richieste vanno solo a lui, indipendentemente dal numero di server. Un blocco del maestro non porta a nuove elezioni. Se non viene scelto alcun maestro, le richieste non vengono gestite.
Volevate scalabilità orizzontale? Mi dispiace, no.
La richiesta a un altro data center va da maestro a maestro, indipendentemente dal server su cui è arrivata. Il maestro scelto riceve il 100% del carico, tranne il carico di inoltro delle richieste. Una copia attuale dei dati è presente su tutti i server del data center, ma risponde solo uno di essi.
L'unico modo per scalare è attivare la modalità stale sul client.
In modalità stale, è possibile rispondere senza quorum. Questa è una modalità in cui rinunciamo alla coerenza dei dati, ma leggiamo un po' più velocemente del solito, e risponde qualsiasi server. Naturalmente, le scritture avvengono solo tramite il master.
Consul non copia i dati tra i data center.Durante la raccolta della federazione, ogni server avrà solo i propri dati. Per gli altri si rivolge sempre a qualcun altro.
L'atomicità delle operazioni non è garantita al di fuori delle transazioni.Ricorda che a modificare qualcosa non sei solo tu. Se desideri farlo diversamente, esegui una transazione con blocco.
Le operazioni di blocco non garantiscono la sincronizzazione.La richiesta va da master a master, non direttamente, quindi non ci sono garanzie che il blocco funzioni quando fai un blocco, per esempio in un altro data center.
Le ACL non garantiscono l'accesso (in molti casi).Le ACL potrebbero non funzionare perché vengono memorizzate in un solo data center della federazione — nel data center delle ACL (Primary DC). Se il DC non risponde, le ACL non funzioneranno.
Un master bloccato porterà alla sospensione dell'intera federazione.. Ad esempio, in una federazione di 10 data center, uno ha una rete scadente e un master che cade. Tutti quelli che comunicano con lui si bloccheranno: arriva una richiesta, non ci sono risposte, il thread si blocca. Non sarà possibile sapere quando accadrà, semplicemente dopo un paio d'ore tutta la federazione crollerà. Non potrete fare nulla al riguardo.
Lo stato, il quorum e le elezioni vengono gestiti in un thread separato. Non ci saranno nuove elezioni, lo stato non mostrerà nulla. Pensate di avere un Consul attivo, fate una richiesta e non succede nulla: non ci sono risposte. Nel frattempo, lo stato mostra che va tutto bene.
Abbiamo affrontato questo problema, e abbiamo dovuto ricostruire parti specifiche dei data center per evitarlo.
Nella versione business di Consul Enterprise mancano alcuni dei difetti sopra menzionati. Ha molte funzionalità utili: selezione dei votanti, distribuzione, scalabilità. C'è solo un 'ma': il sistema di licenze per un sistema distribuito è molto costoso.
Hack della vita: rm -rf /var/lib/consul — la cura per tutte le malattie dell'agente. Se qualcosa non funziona, basta eliminare i propri dati e caricare i dati da un backup. Probabilmente, Consul riprenderà a funzionare.
BEFW
Ora parliamo di cosa abbiamo aggiunto a Consul.
è un acronimo di BackEndFireWall. Dovevo dare un nome al prodotto quando creavo il repository per inserire i primi test commit. Questo nome è rimasto.
Modelli di regole
Le regole sono scritte in sintassi 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 fluisce nella catena BEFW, tranne ESTABLISHED, RELATED e localhost. Il modello può essere qualsiasi, questo è solo un esempio.
Qual è l'utilità di BEFW?
Servizi
Abbiamo un servizio, che ha sempre una porta e un nodo su cui opera. Dal nostro nodo possiamo chiedere localmente all'agente e scoprire che abbiamo un certo servizio. Possiamo anche aggiungere tag.
Qualsiasi servizio avviato e registrato in Consul si trasforma in una regola iptables. Abbiamo SSH — apriamo la porta 22. Lo script Bash è semplice: curl e iptables, non serve altro.
Client
Come concedere accesso non a tutti, ma in modo selettivo? Aggiungere liste IP nello storage KV in base al 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 KV-store pronto. Ora diamo accesso non a tutti, ma in modo selettivo.
Gruppi
Se ogni volta dobbiamo scrivere migliaia di IP per gli accessi, ci stancheremo. Creeremo delle raggruppamenti — un subset separato nel KV. Lo chiameremo Alias (o gruppi) e conserveremo lì i gruppi secondo lo stesso principio.
Colleghiamo: ora possiamo aprire SSH non solo per il P2P, ma per un'intera gruppo o più gruppi. Anche qui esiste TTL — possiamo aggiungere e rimuovere temporaneamente da un gruppo.
Integrazione
Il nostro problema è il fattore umano e l'automazione. Finora l'abbiamo risolto in questo modo.
Lavoriamo con Puppet e trasferiamo tutto ciò che riguarda il sistema (codice delle applicazioni). In puppetdb (un normale PostgreSQL) è memorizzato l'elenco dei servizi attivi, che possono essere trovati per tipo di risorsa. Qui possiamo vedere chi si collega a 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. Inizialmente, i sync dei cookie si collegano a puppetdb. Lì è configurato un API HTTP: chiediamo quali servizi abbiamo e cosa deve essere fatto. Poi viene fatta una richiesta a Consul.
C'è integrazione? Sì: abbiamo scritto le regole, autorizzato l'accettazione delle Pull Request. Hai bisogno di una porta o di aggiungere un host a un gruppo? Pull Request, revisione — niente più "Trova altre 200 ACL e prova a fare qualcosa con questo."
Ottimizzazione
Il ping localhost con una catena di regole vuota richiede 0,075 ms.
Aggiungiamo a questa catena 10.000 indirizzi iptables. Di conseguenza, il ping aumenterà di 5 volte: iptables è completamente lineare, l'elaborazione di ogni indirizzo richiede del tempo.
Per il firewall in cui migriamo migliaia di ACL, abbiamo molte regole, e questo introduce una latenza. È pessimo per i protocolli di gioco.
Ma se mettiamo 10.000 indirizzi in ipset il ping diminuirà anche.
Il punto è che 'O' (complessità dell'algoritmo) per ipset è sempre uguale a 1, indipendentemente da quante regole ci siano. Tuttavia, c'è un limite: non possono esserci più di 65.535 regole. Fino ad allora, viviamo con questo: possiamo combinarle, espandere, creare due ipset in uno.
Archiviazione
Una logica di continuazione del processo di iterazioni è l'archiviazione delle informazioni sui clienti per il servizio in ipset.
Ora abbiamo lo stesso SSH, e non scriviamo subito 100 IP, ma impostiamo il nome ipset con cui comunicare e la regola successiva. ELIMINA. Possiamo riadattarlo in una sola regola "Chi non è qui, viene escluso", ma così è più chiaro.
Ora abbiamo regole e set. L'obiettivo principale è creare il set prima di scrivere la regola, altrimenti iptables non registrerà la regola.
Schema generale
Grafico: tutto ciò di cui ho parlato appare così.
Commettiamo in Puppet, tutto viene inviato all'host, i servizi qui, ipset lì, e chi non è stato registrato lì viene escluso.
Consenti & nega
Per salvare rapidamente il mondo o disconnettere qualcuno velocemente, 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 dei bot. Prima dovevamo trovare il suo IP dai log, portarlo agli ingegneri di rete affinché trovassero la sorgente del traffico e lo bloccassero. Adesso è diverso.
Inviamo a Consul, aspettiamo 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 per errore con il firewall. rules_allow — è la nostra assicurazione contro tali casi. Se commettiamo un errore con il firewall e qualcosa viene bloccato, possiamo sempre inviare un 0.0/0, per ripristinare tutto rapidamente. Poi possiamo sistemare tutto manualmente.
Altri set
Puoi aggiungere qualsiasi altro set nello spazio $IPSETS$.
Perché? A volte qualcuno ha bisogno di ipset, ad esempio per emulare lo spegnimento di una parte del cluster. Ognuno può portare i propri set, dar loro un nome e verranno prelevati da Consul. Questi set possono partecipare alle regole di iptables oppure funzionare come un comando. NOOP: la coerenza sarà mantenuta dal demone.
Utenti
In passato era così: l'utente si connetteva alla rete e tramite il dominio riceveva le impostazioni. Fino all'arrivo dei firewall di nuova generazione, Cisco non era in grado di comprendere dove fosse l'utente e dove fosse l'IP. Pertanto, l'accesso veniva concesso solo tramite hostname della macchina.
Cosa abbiamo fatto? Ci siamo inseriti nel momento in cui viene ottenuto 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 inseriamo l'IP con un TTL che corrisponde al suo dhcp.lease: non appena scade, la regola scomparirà.
Ora possiamo aprire l'accesso ai servizi, come per altri gruppi, in base al nome utente. Abbiamo eliminato il problema con gli hostname quando cambiano e ridotto il carico sugli ingegneri di rete, poiché non hanno più bisogno di Cisco. Ora gli ingegneri scrivono i permessi sui propri server.
Isolamento
Nel frattempo, abbiamo iniziato a esaminare l'isolamento. I manager dei servizi hanno effettuato un'inventario, mentre noi abbiamo analizzato tutte le nostre reti. Le organizziamo in gruppi simili e sui server necessari abbiamo aggiunto i gruppi, per esempio, in deny. Ora lo stesso isolamento di staging passa in rules_deny per la produzione, ma non nella produzione stessa.
Schema semplice e veloce: rimuoviamo tutte le ACL dai server, scarichiamo l'hardware, 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 linters per il controllo delle regole del firewall, era complicato. Ora l'integrità è controllata da BEFW. Si assicura diligentemente che le regole che crea non vengano modificate. Se qualcuno cambia le regole del firewall, le ripristina. 'Ho rapidamente attivato un proxy per lavorare da casa' — non ci sono più opzioni di questo tipo.
BEFW controlla ipset dai servizi e dall'elenco in befw.conf, le regole dei servizi nella catena BEFW. Ma non monitora altre catene e regole e altri ipset.
Protezione da guasti
BEFW conserva sempre l'ultimo stato valido 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 commette un errore utilizzando regole che non possono essere applicate. Per non rimanere senza firewall, BEFW tornerà all'ultimo stato se si verifica un errore in qualche fase.
In situazioni critiche, questa è la garanzia che avremo un firewall funzionante. Apriamo tutte le reti grigie nella speranza che un admin arrivi e le sistemi. Un giorno porterò questo nei configuratori, ma per ora abbiamo solo tre reti grigie: 10/8, 172/12 e 192.168/16. All'interno del nostro Consul, questa è una caratteristica importante che aiuta a progredire.
Demo: durante la presentazione Ivan mostra la modalità demo di BEFW. È più comodo guardare la dimostrazione su . Il codice sorgente della demo è disponibile .
Problemi inaspettati
Parlerò dei bug che abbiamo incontrato.
ipset add set 0.0.0.0/0. Cosa succede se aggiungo in ipset 0.0.0.0/0? Tutti gli IP verranno aggiunti? Si aprirà l'accesso a Internet?
No, stiamo affrontando un bug che ci è costato due ore di inattività. Il bug non è stato risolto dal 2016, è registrato su RedHat Bugzilla con il numero #1297092, e lo abbiamo trovato per caso — grazie a un rapporto del sviluppatore.
Ora in BEFW c'è una regola ferrea 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 di restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Niente di simile — esegue un merge, e i vecchi indirizzi rimangono, non chiudi l'accesso.
Abbiamo trovato il bug mentre testavamo l'isolamento. Ora hanno un sistema piuttosto complesso — invece di restore viene eseguito create temp, poi restore flush temp e restore temp. Alla fine swap: per atomicità, perché se si esegue prima flush e in quel momento arriva qualche pacchetto, verrà scartato e qualcosa andrà storto. Quindi c'è un po' di magia nera.
consul kv get -datacenter=other. Come ho già detto, pensiamo di richiedere dei dati, ma riceveremo o i dati o un errore. Possiamo farlo tramite Consul localmente, ma in questo caso si bloccheranno entrambi.
Il client Consul locale è un wrapper sopra l'API HTTP. Ma semplicemente si blocca e non risponde né a Ctrl+C, né a Ctrl+Z, né a altro, solo a kill -9 nella console adiacente. Ci siamo imbattuti in questo mentre costruivamo un grande cluster. Ma al momento non abbiamo soluzioni, ci stiamo preparando a correggere questo errore in Consul.
Il leader di Consul non risponde. Il master nel nostro data center non risponde, ci chiediamo: "Forse ora funzionerà l'algoritmo di ri-elezione?"
No, non funzionerà e il monitoraggio non mostrerà nulla: Consul dirà che l'indice di commitment c'è, il leader è stato trovato, tutto va bene.
Come affrontiamo questo problema? service consul restart in cron ogni ora. Se hai 50 server, non è un problema. Quando saranno 16.000, capirai come funziona.
Conclusione
Alla fine abbiamo ottenuto i seguenti vantaggi:
- Copertura del 100% di tutte le macchine Linux.
- Velocità.
- Automazione.
- Liberato l'hardware e gli ingegneri di rete dalla schiavitù.
- Sono emerse possibilità di integrazione praticamente illimitate: con Kubernetes, Ansible o Python.
Svantaggi: Consul, con cui ora dobbiamo convivere, e il prezzo dell'errore è molto alto. Ad esempio, una volta, alle 18:00 (ora di punta in Russia), ho modificato qualcosa nelle liste delle reti. Proprio in quel momento stavamo costruendo l'isolamento su BEFW. Ho commesso un errore, suppongo che abbia indicato la maschera sbagliata, e tutto è crollato in due secondi. Il monitoraggio si attiva, l'operatore di supporto corre: «Abbiamo tutto bloccato!» Il capo del dipartimento è invecchiato mentre spiegava al business perché è successo.
Il prezzo dell'errore è così alto che abbiamo ideato una procedura di prevenzione complessa. Se implementate questo in una grande produzione, non date il master token a Consul a tutti indiscriminatamente. Finirà male.
Costo. Ho scritto codice per 400 ore da solo. Il mio team di 4 persone spende 10 ore al mese per supporto su tutti. Rispetto al costo di qualsiasi firewall di nuova generazione, questo è gratuito.
Piani. Il piano a lungo termine è trovare un'alternativa per il trasporto, in sostituzione o in aggiunta a Consul. Potrebbe essere Kafka o qualcosa di simile. Ma nei prossimi anni, continueremo a utilizzare Consul.
Prossimi piani: integrazione con Fail2ban, monitoraggio, nftables, e possibilmente altri distribuzioni, metriche, monitoraggio avanzato, ottimizzazione. Il supporto per Kubernetes è anche nei nostri piani, poiché attualmente abbiamo diversi cluster e una forte motivazione.
Altri piani includono:
- ricerca di anomalie nel traffico;
- gestione della mappa di rete;
- supporto per Kubernetes;
- compilazione di pacchetti per tutti i sistemi;
- Interfaccia Web.
Lavoriamo costantemente per espandere la configurazione, aumentare le metriche e ottimizzare.
Unisciti al progetto. È un progetto interessante, ma purtroppo al momento è solo di una sola persona. Vieni a e prova a contribuire: fare un commit, testare, proporre qualcosa, dare il tuo parere.
Nel frattempo, ci prepariamo per , che si terrà il 6 e 7 aprile a San Pietroburgo, e invitiamo gli sviluppatori di sistemi ad alta capacità . I relatori esperti sanno già come procedere, mentre ai novizi in materia di presentazioni raccomandiamo almeno di . Partecipare alla conferenza come relatore offre diversi vantaggi. Puoi leggere quali sono alla fine. .
Fonte: habr.com
