Quando sono entrato in Cermati nel maggio 2017, non avevamo un team specializzato che si prendesse cura della nostra infrastruttura. All'epoca, un altro responsabile tecnico di Cermati era la persona di riferimento per la maggior parte delle cose relative all'infrastruttura per lo sviluppo e l'infrastruttura di produzione di Cermati. Ma il suo lavoro era, ed è, principalmente nello sviluppo del prodotto.

Mi è capitato di avere una certa conoscenza dell'amministrazione dei sistemi e delle reti di computer e all'epoca sono stato assunto per lavorare al nostro progetto di infrastruttura VoIP. Poiché stavo anche cercando un nuovo dominio su cui concentrarmi dopo circa quattro anni di lavoro come collaboratore presso la mia precedente azienda nelle loro attività di sviluppo del prodotto, il nostro CTO ha deciso di lasciarmi gestire la nostra infrastruttura cloud e le pipeline di dati quando non lavoravo con l'infrastruttura VoIP.

Il nostro team della piattaforma infrastrutturale non si è formato come un vero e proprio team fino a marzo 2018, quando finalmente abbiamo avuto un altro ingegnere interessato all'infrastruttura che si è unito all'azienda.

In questo articolo, vorrei condividere ciò che abbiamo raggiunto negli anni dal 2018 al 2022 che ho notato quando stavo rivisitando i nostri progressi fino ad ora per cercare l'ispirazione per decidere i nostri prossimi passi.

2018

Ero solito gestire l'infrastruttura da solo, ma nel marzo 2018 un nuovo membro del team si è unito per lavorare nel dominio dell'infrastruttura e mi è stato assegnato il compito di supervisionarlo. Quindi, il team della piattaforma dell'infrastruttura è stato ufficialmente formato.

A questo punto, non abbiamo davvero un ambito di lavoro ben definito perché il mio ambito di lavoro all'epoca era praticamente tutto ciò che nessun altro ingegnere possiede realmente, incluso un certo componente nel modulo di back-office del nostro prodotto. Stavo anche lavorando in coppia con un altro ingegnere che non stava lavorando ai nostri progetti infrastrutturali per migliorare la nostra configurazione ETL dopo aver riscontrato diversi problemi con i moduli ETL non mantenuti creati dai nostri precedenti stagisti. Questo status quo è rimasto praticamente lo stesso dopo che abbiamo formato una squadra di due persone.

Lo scopo del lavoro del team della piattaforma dell'infrastruttura era tutto ciò che richiedeva di lavorare a stretto contatto con i componenti dell'infrastruttura, inclusa la pipeline ETL (perché richiede molta interazione con i prodotti dell'infrastruttura dati) e l'infrastruttura VoIP (perché richiede conoscenze di rete e l'hacking del dispositivo VoIP che stavamo usando all'epoca).

A causa della mancanza di una netta separazione tra il lavoro sui dati e il lavoro sull'infrastruttura all'epoca, alcune delle cose che abbiamo costruito rientravano nel dominio dei dati. Stavamo anche cercando di valutare che tipo di miglioramenti avremmo dovuto apportare alla nostra infrastruttura gestendo vari lavori che ci sono caduti in grembo perché nessun altro team ne è proprietario.

Considerando che la configurazione dell'infrastruttura che stavamo utilizzando all'epoca non era molto elaborata e il team era ancora molto piccolo (l'intero team di ingegneri era composto da meno di 15 persone), non c'era una reale necessità di un team di piattaforma di infrastruttura specializzato e il lavoro sull'infrastruttura era praticamente un lavoro saltuario. Ricordo ancora questa volta che ci è stato chiesto di decodificare un'app client per un'applicazione di terze parti con un modello client-server in modo da poter imparare come funziona e consentire al nostro team di prodotto di capire come integrarla meglio con il nostro sistema.

Distribuivamo ancora i nostri servizi direttamente alle istanze di macchine virtuali nel cloud, con Ansible per la gestione della configurazione e l'esecuzione della sequenza di distribuzione.

Ma nella seconda metà del 2018, dopo aver ottenuto una nuova serie di finanziamenti, abbiamo iniziato a preparare la nostra infrastruttura e le nostre pipeline di dati per gestire più carichi e più utenti.

Di seguito sono riportati alcuni dei lavori notevoli che abbiamo svolto nel 2018.

Miglioramento dell'infrastruttura dati

Uno dei lavori che abbiamo svolto nel 2018 è stato riscrivere i nostri moduli di pipeline di dati. La pipeline di dati è stata precedentemente sviluppata da alcuni stagisti nell'arco di pochi anni. Questo ci ha portato a un punto in cui l'oleodotto era rotto e nessuno sa esattamente cosa sia stato rotto perché nessuno possiede l'oleodotto. Quindi ci è stato chiesto di indagare sul problema e ripristinarlo.

L'implementazione creata dai nostri stagisti ha funzionato bene per il volume di dati gestiti durante il loro periodo di tirocinio. Quel volume è cresciuto molto nel 2018 e la pipeline è stata sovraccaricata e ridotta dal volume di dati che doveva gestire.

All'epoca c'erano anche operazioni pesanti che dipendevano da Apache Spark, che richiedevano che la VM che eseguiva le pipeline ETL fosse abbastanza grande. Se non ricordo male, aveva circa 16 GB di memoria. Alla fine, abbiamo eliminato Spark dal flusso di lavoro ETL e riscritto la pipeline per utilizzare solo codice Python vanilla e Panda per il processo di trasformazione dei dati. La pipeline è quindi stata eseguita senza problemi e abbiamo potuto eseguire il downgrade della macchina a una VM più piccola con solo 4 GB di memoria.

Un'altra cosa che abbiamo risolto è stato il modo in cui i dati sono stati caricati nella nostra infrastruttura OLAP nel cloud. Successivamente, il team dell'infrastruttura ha posseduto la pipeline di dati e il cluster OLAP per un po', fino alla formazione del team della piattaforma dati nel 2019.

Abbiamo anche apportato alcune modifiche alla suite di server VoIP che stavamo utilizzando per migliorare il flusso dell'elaborazione dei dati nei nostri sforzi per migliorare il flusso di lavoro dell'elaborazione dei dati dai server VoIP alla nostra pipeline di dati di analisi aziendale.

Adozione di Prometeo e sviluppo di Fotia

Utilizzavamo NewRelic per il monitoraggio e gli avvisi delle prestazioni delle nostre applicazioni, ma abbiamo iniziato a esplorare modi per consentirci di acquisire più metriche dal runtime dell'applicazione per monitorare il nostro ambiente di produzione e le canalizzazioni della pipeline del prodotto.

Prometheus sembrava essere una scelta ovvia, quindi abbiamo deciso di esplorare come configurarlo in modo che le metriche dei nostri servizi possano essere raccolte da Prometheus. Prometheus può recuperare le metriche estraendole dall'endpoint delle metriche esposto dal servizio oppure il servizio può inviare le metriche a Prometheus. Abbiamo trovato il primo più semplice da configurare, quindi abbiamo optato per il primo.

All'epoca i nostri servizi erano tutti sviluppati utilizzando NodeJS e c'era un problema con la libreria NodeJS di Prometheus che stavamo utilizzando. Stavamo eseguendo il server back-end NodeJS con più processi e ogni processo mantiene le proprie metriche. Ogni volta che Prometheus tenta di raschiare le metriche, ottiene solo le metriche da uno dei processi e il processo le cui metriche sono state fornite a Prometheus sembrava essere casuale.

Per risolvere questo problema, abbiamo sviluppato Fotia, un servizio interno che utilizziamo per raccogliere le metriche dai nostri servizi da servire a Prometheus. Quindi Prometheus deve solo raschiare le metriche dall'endpoint del servizio Fotia, dove tutte le metriche che vorremmo monitorare sono state raccolte in un unico posto. Fotia ha utilizzato Redis per archiviare le metriche e i dati più vecchi possono essere dimenticati poiché non verranno più forniti a Prometheus.

Fotia è stato ritirato nel 2019 dopo l'adozione di Kubernetes poiché abbiamo configurato i pod che eseguono i servizi NodeJS per eseguire solo un'istanza del processo NodeJS per pod, il che ha eliminato la condizione che ci ha portato a creare Fotia in primo luogo.

Bot Slack per la distribuzione dei servizi

Durante la seconda metà del 2018, abbiamo iniziato a prepararci a ridimensionare la nostra organizzazione. Il nostro CTO ha richiesto che iniziassimo ad applicare regole rigide su chi dovrebbe essere autorizzato ad accedere alla nostra rete di produzione.

Ciò ci ha richiesto di ripensare la nostra configurazione di distribuzione poiché richiedevamo ai nostri ingegneri di eseguire playbook Ansible direttamente da una delle macchine nella rete di produzione per attivare le distribuzioni di servizi. Mentre l'accesso alle altre macchine era limitato, l'accesso alla macchina di distribuzione è stato concesso a molti dei nostri ingegneri per consentire loro di distribuire i servizi di cui sono proprietari.

Abbiamo deciso di sviluppare un servizio di back-end che viene eseguito sulla macchina di distribuzione per attivare i playbook di distribuzione come richiesto dagli ingegneri che eseguono la distribuzione, quindi gli ingegneri non hanno più bisogno di accedere alla rete di produzione per eseguire la distribuzione. Gli ingegneri possono comunicare con questo servizio interagendo con un bot nel loro canale Slack di coordinamento della distribuzione. Noi (gli ingegneri dell'infrastruttura) chiamiamo questo bot ChatOps, ma ogni team di sviluppo prodotto è libero di nominare il bot nel proprio canale Slack come desidera, quindi abbiamo avuto alcuni nomi divertenti lì.

ChatOps ha la capacità di mantenere una regola di controllo degli accessi. Pertanto, possiamo configurarlo per rispondere solo ai comandi invocati da persone autorizzate a eseguire distribuzioni.

L'utilizzo di ChatOps è passato di moda dopo l'adozione di Kubernetes, poiché in seguito abbiamo sviluppato uno strumento più potente chiamato svctlper eseguire la sequenza di creazione e distribuzione del software. Ma ChatOps è ancora utilizzato da alcuni team anche nel momento in cui questo articolo è stato scritto nel gennaio 2023.

ChatOps non è più sotto la responsabilità del team della piattaforma dell'infrastruttura, poiché abbiamo abbandonato il supporto perché non fa più parte dei nostri servizi di infrastruttura di base e vogliamo concentrare la nostra attenzione sulla manutenzione degli altri servizi e strumenti. Ma uno dei team di sviluppo del prodotto ha scoperto che alcune delle funzionalità fornite da ChatOps sono piuttosto utili per migliorare il proprio flusso di lavoro di sviluppo anche dopo la migrazione a per la distribuzione del servizio svctle ha deciso di assumere la proprietà di ChatOps dopo che il team della piattaforma dell'infrastruttura smesso di mantenerlo. Quindi immagino che sia un prodotto interno di grande successo.

2019

Il 2019 è stato l'anno in cui abbiamo iniziato a gettare le basi per lo sviluppo delle nostre infrastrutture nei prossimi anni. Un nuovo membro del team della piattaforma infrastrutturale è entrato a far parte del team a gennaio 2019. Con un ingegnere aggiuntivo a bordo, potremmo iniziare a suddividere meglio il nostro lavoro e aumentare la nostra capacità.

La proprietà dei componenti dei dati è stata assunta dal team della piattaforma dati in questo periodo e abbiamo iniziato ad avere una migliore separazione tra i componenti di proprietà del team della piattaforma dell'infrastruttura e i componenti di proprietà del team della piattaforma dati. In un certo senso, perché ci sono cose che abbiamo costruito e che non possono essere consegnate così agevolmente fino a un po' più tardi. Inoltre, alcuni dei componenti di dati distribuiti nella nostra infrastruttura sono ancora strettamente collegati all'infrastruttura stessa, quindi sono rimasti in un'area grigia riguardo a chi dovrebbe possederli.

Abbiamo iniziato a sviluppare un'idea di come dovrebbe essere l'infrastruttura in futuro e abbiamo investito di più nello sviluppo e nella standardizzazione dei nostri strumenti interni. Abbiamo sviluppato BCL per definire l'interfaccia e la struttura standard per gli strumenti interni basati su CLI che gestiscono anche il flusso di lavoro di distribuzione degli strumenti - abbiamo anche scritto un articolo a riguardo - e abbiamo iniziato a muoverci verso l'adozione di Kubernetes. BCL è uno strumento molto semplice che abbiamo creato rapidamente all'inizio del 2019, ma alimenta alcuni degli strumenti di cui parleremo nelle sezioni successive: svctl, dbctle pkictl.

Di seguito sono riportati alcuni dei lavori notevoli che abbiamo svolto nel 2019.

Strumento di replica del database

Stavamo aiutando il team della piattaforma dati a migliorare la pipeline di importazione dei dati dai server VoIP nei nostri call center al loro data warehouse, poiché gli è stato chiesto di ridurre l'intervallo di tempo per il trasporto dei dati nel data warehouse per abilitare la business intelligence team per fornire dashboard di analisi in tempo reale al nostro team operativo aziendale.

In precedenza, utilizzavamo alcuni hack implementati quando ci veniva chiesto di assistere il team dell'infrastruttura IT del call center. Ma il modo in cui è stato implementato, è piuttosto difficile trasportare in modo affidabile solo modifiche incrementali al loro data warehouse eseguendo query sul server MariaDB in batch. La struttura della tabella del database dell'appliance VoIP e il modo in cui le colonne vengono aggiornate ci rendono difficile migliorare la query per soddisfare le esigenze del team di business intelligence.

Abbiamo finito per creare myshipperper risolvere questo problema, che è un'utilità di replica del database per MySQL e MariaDB per spedire in modo incrementale i file binlog del database a un archivio di oggetti cloud per essere archiviati e quindi recuperati da un lavoratore nel nostro data warehouse. L'utilizzo di myshipperè stato successivamente deprecato nel 2022, poiché la nostra configurazione dell'infrastruttura di rete nel 2022 ci consente di utilizzare direttamente le funzionalità di replica native di MariaDB per replicare direttamente i dati in un'istanza database di replica all'interno del segmento di rete del data warehouse.

Adozione di Kubernetes e strumenti di distribuzione di servizi/DB

Abbiamo deciso di puntare all'adozione di Kubernetes nel 2019. Per promuovere l'adozione di Kubernetes, dovevamo definire una serie di standard che i nostri servizi devono rispettare per semplificarci la vita dopo l'adozione di Kubernetes. Questi standard sono diventati il ​​contratto tra gli ingegneri e la nostra infrastruttura e sono stati quindi formalizzati sotto forma di svctl, il nostro strumento di utilità per la creazione e l'implementazione dei servizi.

svctlautomatizza il processo di configurazione del flusso di lavoro di build e containerizzazione del servizio, insieme alla sequenza di distribuzione ai nostri cluster Kubernetes. svctlè stato inizialmente creato come wrapper lato client che kubectlha anche la capacità di generare configurazioni standardizzate per generare il dashboard di monitoraggio per i servizi in Grafana ed eseguire pipeline di compilazione su Jenkins. svctlL'architettura di verrà pesantemente modificata nel 2021 per trasformarla in un'architettura lato client, di cui parleremo in una sezione successiva.

Oltre a svctl, un altro strumento importante che abbiamo implementato per migliorare la standardizzazione del flusso di lavoro per la gestione dell'infrastruttura è stato dbctl(da non confondere con questo DBCTL ). Se svctlviene utilizzato per standardizzare il ciclo di vita della creazione e dell'implementazione del nostro servizio, dbctlviene utilizzato per standardizzare il provisioning e la gestione dell'istanza del database cloud gestito, nonché il server del database e la gestione degli accessi. dbctlsfrutta Terraform per l'interfacciamento con le funzionalità di gestione delle istanze di database gestite della piattaforma cloud di destinazione e fornisce un framework per l'esecuzione di operazioni di database amministrative per gli schemi e le tabelle del database.

Infrastruttura a chiave pubblica

Abbiamo già scritto alcuni articoli sulla PKI (Public Key Infrastructure) prima:

• Implementazione pratica dell'infrastruttura a chiave pubblica presso Cermati
• Integrazione dell'infrastruttura a chiave pubblica con Vault Secrets Manager

Inizialmente l'abbiamo sviluppato come parte dei nostri strumenti di sviluppo interni che sono strettamente collegati al flusso di lavoro e all'infrastruttura di sviluppo, il che gli ha fatto utilizzare gli account GitHub degli sviluppatori come fonte di identità e ha richiesto un uso massiccio di Git per i processi di richiesta e firma dei certificati — poiché l'elenco dei certificati firmati al momento era archiviato in un repository Git.

Abbiamo presto visto il suo potenziale per essere utilizzato in un contesto più ampio, quindi non molto tempo dopo l'iterazione iniziale abbiamo deciso di riscriverne una parte importante in modo che possa utilizzare Google Workspace della nostra azienda come fonte di identità della verità e utilizzare un database adeguato per l'archiviazione l'elenco dei certificati validi dei dipendenti. È stata inoltre sviluppata un'applicazione desktop GUI chiamata PKI Toolbox per supportare i dipendenti meno tecnici e abbiamo creato PKI Toolbox per Windows, Linux e Mac OS, poiché pkictlè utilizzabile solo su Linux e Mac OS ed è un'applicazione CLI che lo rende più difficile da usare per i dipendenti non tecnici.

Una volta che la PKI è utilizzabile per le nostre divisioni non ingegneristiche, abbiamo iniziato a integrare la nostra autenticazione VPN con la nostra PKI in modo che i certificati rilasciati ai nostri dipendenti possano essere utilizzati per accedere ai loro account VPN. A tal fine, abbiamo anche aggiunto funzionalità extra all'applicazione PKI Toolbox in modo che possa essere utilizzata per generare configurazioni VPN per i suoi utenti, migliorando l'esperienza dei nostri dipendenti quando hanno bisogno di accedere a un server VPN diverso.

Dopo aver integrato il flusso di lavoro di autenticazione VPN nella nostra PKI e visto che era un successo, abbiamo fatto lo stesso anche per la nostra gestione degli accessi SSH e abbiamo sviluppato CSSH per integrare il nostro flusso di lavoro di accesso SSH con la nostra PKI. CSSH ha quattro componenti: cssh-authzback-end del server che contiene la definizione della regola di controllo degli accessi per l'autorizzazione CSSH, modulo CSSH PAM distribuito su ciascuno dei nostri server per consentire ai server SSH di utilizzare la nostra PKI per l'autenticazione, che viene eseguito sulle nostre macchine per gestire gli utenti cssh-daemonSSH sulle suddette macchine, e csshctlviene eseguito sulle workstation dei nostri ingegneri per generare certificati SSH di breve durata che possono utilizzare quando accedono alle nostre macchine tramite SSH.

Mantenere il controllo degli accessi per i server VPN e SSH era ancora una seccatura a questo punto. Il controllo degli accessi dei server VPN è stato mantenuto localmente in ogni istanza del server VPN e deve essere popolato manualmente utilizzando Ansible ogni volta che c'è un aggiornamento. La regola di controllo degli accessi SSH era già memorizzata e gestita da un cssh-authzservizio di backend centrale, ma avevamo anche bisogno di utilizzare Ansible per aggiornare le regole quando era necessario effettuare un aggiornamento. Questo problema sarà affrontato dai componenti che abbiamo costruito negli anni successivi.

2020

Abbiamo continuato a costruire sulle basi gettate l'anno precedente per migliorare i nostri processi infrastrutturali e i flussi di integrazione dei componenti quest'anno. Avevamo un amministratore di database alla fine del primo trimestre, insieme a due analisti della sicurezza alla fine del quarto trimestre.

I restanti componenti dei dati, la cui proprietà era ancora confusa tra la piattaforma dell'infrastruttura e i team della piattaforma dati, sono stati infine consegnati al team della piattaforma dati. Lo abbiamo fatto sfruttando la configurazione di Kubernetes che abbiamo creato l'anno precedente e spostato l'implementazione dei componenti rimanenti su Kubernetes, che consente al team della piattaforma dati di modificare l'ambiente di runtime senza influire sulla stabilità dell'infrastruttura di livello inferiore e consente loro efficacemente possedere l'intero stack di dati.

Abbiamo anche iniziato a progettare e sviluppare un dashboard di controllo e gestione degli accessi basato sul Web che in seguito fungerà da piattaforma IAM (Identity Access Management) a livello aziendale.

Di seguito sono riportati alcuni dei lavori notevoli che abbiamo svolto nel 2020.

Sostituzione di Nginx con OpenResty

Uno dei principali cambiamenti che abbiamo apportato è stato sostituire la nostra configurazione Nginx con una nuova configurazione OpenResty. In precedenza, i nostri server Nginx venivano distribuiti direttamente su una VM cloud rivolta al pubblico situata nell'area del nostro segmento di rete DMZ.

Sebbene la vecchia configurazione di Nginx funzionasse abbastanza bene per noi, questa configurazione poneva alcune limitazioni al flusso di lavoro delle nostre operazioni.

In primo luogo, poiché l'implementazione delle modifiche alla configurazione di Nginx, anche solo per un semplice aggiornamento del percorso comunemente richiesto dagli sviluppatori, richiede di eseguire playbook Ansible sulla VM cloud e applicare le modifiche direttamente alla macchina, qualsiasi errore durante l'esecuzione rischia facendo crollare l'intero sito. A seconda del tipo di errore verificatosi durante l'operazione, potremmo non essere in grado di recuperare abbastanza velocemente.

In secondo luogo, a causa del potenziale rischio dell'operazione per questa configurazione, eravamo riluttanti a scaricare anche solo un semplice atto di aggiunta di nuovi percorsi agli sviluppatori. Per non parlare del fatto che gli sviluppatori avranno bisogno di accedere all'istanza di VM cloud Nginx, il che potrebbe essere un altro problema poiché il numero di sviluppatori che autorizziamo ad apportare le modifiche aumenta. Ciò ha portato a limitare qualsiasi modifica alle configurazioni di Nginx per essere eseguita solo dal team della piattaforma dell'infrastruttura.

In terzo luogo, avevamo solo un'istanza Nginx che fungeva da gateway per la nostra applicazione, rendendola un singolo punto di errore. Potremmo distribuire un server Nginx ridondante su un'altra istanza di cloud VM e impostare un meccanismo di failover se uno dei server si guasta per qualche motivo, il che potrebbe essere alquanto complicato da configurare e potrebbe comunque causare un notevole disturbo ai nostri utenti. Oppure possiamo provare un altro approccio sfruttando Kubernetes, poiché abbiamo già configurato Kubernetes in precedenza e Kubernetes fornisce già le funzionalità di auto-riparazione che possiamo utilizzare.

Per risolvere questi problemi, abbiamo deciso di containerizzare la nostra configurazione Nginx da distribuire su Kubernetes utilizzando svctl, il che rende molto più conveniente distribuire nuove configurazioni Nginx ai nostri VPC. Abbiamo anche sostituito il vanilla Nginx che usavamo in precedenza con OpenResty, che è fondamentalmente solo Nginx, ma con funzionalità di scripting Lua.

Con OpenResty abbiamo implementato alcuni moduli Lua che contengono logica aggiuntiva da inserire nelle regole di routing. Abbiamo anche ristrutturato le configurazioni del server per rendere più facile per gli sviluppatori aggiungere i loro percorsi applicativi alla configurazione esistente, permettendoci di scaricare gran parte del lavoro sugli sviluppatori stessi mentre ci tenevamo in disparte solo come revisori per la configurazione cambia.

Redash su Kubernetes

All'epoca, la maggior parte dei componenti dei dati che il team della piattaforma dell'infrastruttura sviluppava era già di proprietà del team della piattaforma dei dati. Ma abbiamo riscontrato un problema con Redash perché utilizzava ancora la nostra vecchia configurazione in cui Redash veniva distribuito direttamente su una VM cloud, questo rende difficile per il team della piattaforma dati eseguire aggiornamenti e modifiche al nostro Redash perché potrebbe influire sul cloud La stabilità della VM e se qualcosa è rotto potrebbero aver bisogno dell'aiuto del team della piattaforma dell'infrastruttura per risolverlo.

Quindi, proprio come abbiamo fatto con OpenResty nella sezione precedente, abbiamo anche riconfigurato la nostra configurazione di distribuzione Redash per consentirne la containerizzazione e la distribuzione su Kubernetes, consentendo al team della piattaforma dati di possedere l'intera configurazione di Redash senza il rischio di rompere nulla su l'infrastruttura che potrebbe richiedere del lavoro per essere riparata.

C'è una cosa unica in questa configurazione di Redash rispetto agli altri servizi che abbiamo distribuito su Kubernetes in precedenza. La configurazione di Redash richiedeva molta memoria per i suoi pod a causa della necessità di caricare molti dati dal database per scopi di analisi. Per questo motivo, dovevamo fornire un set speciale di nodi di lavoro per la distribuzione Redash e configurato il cluster Kubernetes per utilizzare quei nodi di lavoro speciali per la distribuzione Redash con contaminazioni .

Dopo aver completato questa configurazione, abbiamo praticamente eliminato la manutenzione di Redash dal nostro lavoro.

Sviluppo IAMX

La nostra organizzazione stava crescendo rapidamente e ci sono molte attività di provisioning degli accessi che dovevano essere eseguite. Nel modo in cui lo stavamo facendo, abbiamo perso una notevole quantità di tempo per fornire account per nuovi entrati nei nostri team di prodotto e ingegneri. Le stesse attività di provisioning dell'accesso sono piuttosto ripetitive e teoricamente dovremmo essere in grado di automatizzarle se disponiamo di una buona interfaccia standardizzata per le piattaforme su cui stiamo fornendo l'accesso utente.

Poiché non disponevamo di un'interfaccia standardizzata per le piattaforme di destinazione, abbiamo deciso di crearne una noi stessi. Quindi abbiamo iniziato a progettare e sviluppare IAMX (Identity Access Management eXecutor).

IAMX funge da motore per convalidare il supporto dell'interfaccia per le piattaforme di destinazione implementate nei moduli plug-in che abbiamo definito connettori IAMX ed esegue anche la logica di provisioning, recupero e revoca dell'accesso implementata nei connettori IAMX.

Abbiamo progettato IAMX in modo da consentire lo sviluppo indipendente dei moduli del connettore IAMX da parte di persone di altri team o anche di altre società, se qualcuno di un'altra società è interessato a implementarne uno per il proprio caso d'uso e pubblicare il codice come progetto open source — e quindi inserito nell'applicazione che esegue IAMX in modo che IAMX possa sfruttare il modulo del connettore IAMX per eseguire attività di gestione degli accessi sulla piattaforma di destinazione a cui è connesso.

IAMX di per sé non è molto utile poiché può essere utilizzato solo per attivare azioni di provisioning e revoca dell'accesso alle piattaforme di destinazione e nient'altro. Per questo motivo, dobbiamo creare un'altra applicazione, con IAMX come nucleo, per gestire i flussi di lavoro dei processi IAM end-to-end dell'azienda. Così, abbiamo iniziato a progettare e sviluppare IAMD (Identity Access Management Dashboard) che implementa l'intero flusso di business per il processo IAM interno di Cermati.

IAMD è stato lanciato nel primo trimestre del 2021, quindi ne parleremo di più in una sezione successiva.

2021

Abbiamo più persone nel nostro team nel primo trimestre: un analista della sicurezza e due ingegneri del software.

In questo periodo, abbiamo concentrato i nostri sforzi principalmente sul miglioramento delle nostre capacità di sicurezza e governance delle operazioni infrastrutturali. Con il nuovo team di sicurezza delle informazioni che lavora con noi, abbiamo anche implementato nuovi processi e strutture per consentirci di gestire il nostro sistema in modo ancora più sicuro.

Avevamo ridotto gran parte del nostro lavoro sul supporto al team di sviluppo impostando in precedenza la distribuzione di OpenResty su Kubernetes. Abbiamo anche interrotto il nostro lavoro per supportare il team della piattaforma dati nella gestione della loro configurazione Redash distribuendo le istanze Redash su Kubernetes.

Ma avevamo ancora molto lavoro manuale da fare per quanto riguarda la gestione degli accessi. Abbiamo sviluppato IAMX l'anno precedente, ma dovevamo ancora terminare lo sviluppo di IAMD per eliminare finalmente il lavoro IAM manuale.

Di seguito sono riportati alcuni dei lavori notevoli che abbiamo svolto nel 2021.

IAMD

Abbiamo già articoli scritti su IAMD prima:

• Migliorare la gestione degli accessi alle identità in Cermati
• Gestione centralizzata dell'identità e degli accessi al cloud in Cermati

Come accennato in una sezione precedente, nel 2019 abbiamo integrato il nostro flusso di lavoro di autenticazione SSH e VPN con la nostra PKI. Ma il modo in cui abbiamo mantenuto le regole di controllo degli accessi ai fini dell'autorizzazione era ancora piuttosto disordinato.

Volevamo integrarli entrambi (gestione dell'accesso SSH e VPN) con IAMD per eliminare il lavoro manuale che dovevamo eseguire (apportare modifiche manuali ai playbook Ansible, ottenere la revisione delle modifiche ed eseguire i playbook) al fine di fornire l'accesso al nostro Server VPN e SSH. Ma a causa della confusione con la gestione del controllo degli accessi, la creazione di connettori IAMX per regolare direttamente la regola di controllo degli accessi esistente in base alle operazioni eseguite in IAMD non ci è sembrata una buona idea.

Quindi abbiamo sviluppato un servizio intermedio chiamato Torii, che utilizza Ory Keto per gestire le regole di accesso, che funge da interfaccia per IAMX con cui comunicare per gestire le regole di controllo degli accessi ai nostri server SSH e VPN. Abbiamo quindi proceduto alla migrazione delle nostre regole di accesso SSH e VPN a Keto in modo che possa essere gestita in un unico posto. Infine, abbiamo creato un modulo connettore IAMX per Torii per gestire i flussi di lavoro SSH e VPN IAM e quindi abbiamo inserito il connettore IAMX in IAMD.

Abbiamo anche sfruttato Torii per implementare la nostra integrazione della gestione del controllo degli accessi del cluster Kubernetes con IAMD, che ha completato il nostro obiettivo di unificare il flusso di lavoro IAM di tutti i nostri componenti dell'infrastruttura in IAMD.

Ammodernamentosvctl

svctl, il nostro strumento di creazione e distribuzione dei servizi, è stato sviluppato come wrapper lato client per varie operazioni Kubernetes e Jenkins per migliorare l'esperienza di sviluppo dei nostri ingegneri durante lo sviluppo di servizi per i loro domini.

Ma svctll'esecuzione di tutta la logica richiesta in uno strumento CLI che risiede nelle macchine degli sviluppatori ci ha reso difficile apportare modifiche sostanziali all'infrastruttura senza doverci coordinare con gli sviluppatori per deprecare la versione che stavano utilizzando e svctlaggiornarla svctlall'ultima version - che a volte ha molte incompatibilità con la versione che stanno usando, specialmente se hanno molte versioni indietro.

Per risolvere questo problema, abbiamo deciso di eseguire un importante rinnovamento dell'architettura su svctl, in cui la nuova versione sarebbe stata un'applicazione client-server con svctlla sola funzione di thin client che comunica con svapp, un servizio di back-end che esegue la logica di base precedentemente gestita da svctla eseguire operazioni sui nostri cluster Jenkins e Kubernetes.

Con questa nuova configurazione client-server, possiamo essere più aggressivi nel migliorare la nostra infrastruttura di creazione e consegna del software e il flusso di lavoro senza preoccuparci troppo dei cambiamenti che interessano i nostri sviluppatori. Ciò è dovuto al fatto che possiamo semplicemente implementare un aggiornamento per svapprispettare le nostre modifiche all'infrastruttura e fare in modo che gli sviluppatori utilizzino la svctlversione che hanno utilizzato senza alcun disturbo da parte loro, purché l'interfaccia tra svctle svappmantenga la sua retrocompatibilità.

E se vogliamo deprecare le vecchie versioni del svctlthin client, possiamo semplicemente inserire l'avviso di deprecazione come parte della risposta che deve essere mostrata dalle svctlversioni interessate agli sviluppatori in modo che il flusso di comunicazione dell'avviso di deprecazione possa essere semplificato.

Miglioramenti della sicurezza dell'infrastruttura

Con il team di sicurezza delle informazioni a bordo, abbiamo iniziato a lavorare per promuovere ulteriori miglioramenti nella configurazione della sicurezza dell'infrastruttura.

Dal punto di vista del processo e del monitoraggio, abbiamo riprogettato le nostre regole di accesso GCP per semplificarne la gestione e applicato una struttura di autorizzazione più rigorosa per ridurre le possibilità che a un dipendente venga concesso un accesso eccessivo oltre a quello di cui ha bisogno per svolgere le proprie funzioni lavorative. Abbiamo anche importato i log delle attività della nostra infrastruttura in Wazuh per migliorare la struttura di controllo dei log e di avviso che avevamo in atto.

Abbiamo anche applicato MFA con TOTP al nostro flusso di lavoro di accesso VPN e SSH per renderlo ancora più sicuro. Utilizziamo PrivacyIDEA per il back-end del sistema di autenticazione TOTP.

Dal momento che abbiamo anche ricevuto indicazioni dal top management per perseguire la certificazione PCI-DSS, abbiamo iniziato a riprogettare la configurazione della nostra infrastruttura per l'implementazione dei servizi relativi ai pagamenti per soddisfare i requisiti PCI-DSS relativi alla sicurezza dei segmenti di rete dell'ambiente dei dati dei titolari di carta e della rete segmenti dei componenti che si interfacciano con esso. Non siamo riusciti a ottenere l'audit per la conformità PCI-DSS nel 2021, ma abbiamo superato l'audit e ottenuto la certificazione nel 2022.

2022

Ora che abbiamo praticamente eliminato la maggior parte del lavoro manuale che appesantisce il nostro lavoro quotidiano, possiamo investire di più nel miglioramento dell'architettura, degli strumenti e dei processi del nostro sistema che prima non riuscivamo a toccare. Abbiamo anche ampliato ancora una volta il nostro team e abbiamo avuto un altro analista della sicurezza che si è unito a noi nell'aprile 2022.

Il nostro obiettivo principale nel 2022 è stato ridimensionare le capacità dell'organizzazione per sfruttare la nostra infrastruttura, migliorando al contempo la posizione di sicurezza complessiva dell'organizzazione in aspetti rilevanti per l'utilizzo dei nostri servizi di infrastruttura. Abbiamo anche migliorato il nostro toolkit per gestire meglio la nostra infrastruttura su larga scala e ottimizzato le nostre configurazioni di sistema esistenti per semplificarne la manutenzione, fornendo al contempo un servizio migliore agli utenti.

Nel 2021, abbiamo riprogettato l'architettura dell'infrastruttura del nostro sistema di pagamento per renderla conforme allo standard PCI-DSS. Nel 2022, abbiamo migliorato gli altri aspetti dei nostri standard operativi di sicurezza per soddisfare i requisiti di conformità PCI-DSS e abbiamo organizzato la verifica del nostro sistema. Abbiamo superato l'audit e ottenuto il nostro certificato di conformità PCI-DSS.

Di seguito sono riportati alcuni dei lavori notevoli che abbiamo svolto nel 2022.

Miglioramenti alla configurazione di Jenkins

Avevamo pianificato di migliorare la configurazione di Jenkins per consentire ai nostri sviluppatori e ingegneri di test di definire le proprie pipeline Jenkins personalizzate, ma la nostra configurazione iniziale di Jenkins era pericolosa perché le pipeline personalizzate potevano essere utilizzate per distruggere il cluster Jenkins o esfiltrare informazioni di sistema riservate contenute all'interno della rete segmento eseguendo codice dannoso sulla pipeline Jenkins. Pertanto, il team dell'infrastruttura doveva essere quello che creava pipeline personalizzate come richiesto dagli sviluppatori e dagli ingegneri di test ogni volta che ne avevano bisogno.

Ciò è dovuto al fatto che i nostri lavoratori Jenkins sono stati distribuiti direttamente su macchine virtuali cloud all'interno dello stesso segmento di rete del resto dei nostri servizi di infrastruttura, il che lo rendeva soggetto a interruzioni se una pipeline è configurata per eseguire comandi che interrompono qualcosa nell'host lavoratore mentre il lavoratore ospita sono autorizzati ad accedere ad alcune risorse relative all'infrastruttura all'interno dello stesso segmento di rete.

Per evitare questi problemi, abbiamo eseguito il provisioning di un nuovo cluster Jenkins all'interno di un segmento di rete separato e i nodi di lavoro di questo nuovo cluster Jenkins vengono distribuiti come contenitori su un cluster Kubernetes. Questo nuovo cluster Jenkins è sicuro per i nostri sviluppatori e ingegneri di test per armeggiare e definire pipeline personalizzate, eliminando il team della piattaforma dell'infrastruttura dall'essere il collo di bottiglia per le loro esigenze di pipeline personalizzate. Come bonus, abbiamo configurato il cluster in modo che venga ridimensionato automaticamente per risparmiare sui costi durante il periodo in cui il carico del cluster Jenkins è basso, cosa che non avevamo impostato sul vecchio cluster Jenkins.

Un problema che avevamo inizialmente con il nostro nuovo cluster Jenkins era che doveva estrarre tutti i commit Git dal repository da cui stava estraendo ogni volta che veniva eseguita la pipeline, invece di estrarre semplicemente le ultime modifiche come con la nostra vecchia configurazione di Jenkins, dove il gli ultimi commit dei pull Git precedenti vengono archiviati nel disco, pronti per essere riutilizzati dalle successive esecuzioni della pipeline.

A causa delle nostre nuove pipeline Jenkins in esecuzione all'interno di un container su un cluster Kubernetes, i repository clonati non potevano essere riutilizzati dalle successive esecuzioni della pipeline. Per risolvere questo problema, abbiamo impostato un meccanismo per memorizzare nella cache il risultato delle precedenti operazioni di clonazione e pull di Git per le successive esecuzioni della pipeline da utilizzare, il che ha accelerato notevolmente le prestazioni di runtime della pipeline per i nostri repository precedenti, che hanno un numero significativamente maggiore di commit rispetto al più recente quelli ed è stato gravemente influenzato dalla necessità di eseguire il pull di ogni commit ogni volta che viene eseguita la pipeline.

Questi miglioramenti del cluster Jenkins potrebbero essere implementati in tempi relativamente brevi grazie al svctlrinnovamento che abbiamo fatto nell'anno precedente, consentendoci principalmente di interfacciarci solo con svappil back-end durante la configurazione del nuovo cluster Jenkins senza interrompere il flusso di lavoro degli sviluppatori.

Processo di sicurezza e strumenti

A partire dall'anno precedente, il team di sicurezza delle informazioni, che ora è una suddivisione all'interno del team della piattaforma dell'infrastruttura, ha iniziato a sperimentare i nostri processi e le nostre tecnologie di sicurezza. Una delle cose che abbiamo iniziato a fare sono state le campagne di phishing interne, che sono integrate nei nostri programmi di sensibilizzazione alla sicurezza per formare i nostri dipendenti a riconoscere le minacce di phishing.

La prima campagna di phishing che abbiamo condotto nel 2021 è stata eseguita con strumenti minimi, quindi abbiamo provato a condurre un'altra campagna di phishing con un'esecuzione di prova di un toolkit per campagne di phishing a pagamento. Il toolkit non ha davvero soddisfatto le nostre aspettative, quindi abbiamo deciso di non abbonarci.

Dopo alcune discussioni, abbiamo iniziato a pensare di sviluppare il nostro toolkit per la campagna di phishing e abbiamo deciso di svilupparne uno da soli. Il toolkit della campagna di phishing risultante ha le funzionalità di cui avevamo bisogno per consegnare le e-mail di phishing agli obiettivi, analizzare la consegna e il tasso di apertura delle e-mail di phishing e fino a che punto le vittime si erano inoltrate nella canalizzazione di phishing.

Abbiamo anche applicato regole più rigide alle nostre configurazioni del firewall per applicazioni Web Cloud Armor, che sono attentamente monitorate dal nostro team di sicurezza delle informazioni per gli attacchi in corso e le potenziali modifiche che possiamo apportare al nostro set di regole.

Per la sicurezza dei nostri interni di rete VPC, abbiamo deciso di applicare regole firewall di rete più rigide per il nostro VPC interno. Ma questo è un po' difficile da gestire per noi, quindi abbiamo deciso di creare uno strumento di gestione del firewall di rete che ci consenta di gestire le regole del firewall in un modo più conveniente, consentendo al tempo stesso un migliore coordinamento con gli sviluppatori per la gestione delle regole del firewall all'interno del loro staging e reti VPC di produzione.

Per aiutarci a rilevare potenziali minacce che riescono a entrare nei nostri segmenti di rete VPC, abbiamo anche impostato alcuni honeypot, che attivano un allarme a cui il team di sicurezza delle informazioni deve rispondere se vengono rilevate attività sospette sugli honeypot.

Database e infrastruttura per lo scambio di dati

L'integrazione dell'infrastruttura di rete tra il nostro sito di call center e il nostro data warehouse aveva subito alcuni miglioramenti nel corso degli anni ed eravamo già al punto in cui potevamo configurare i database del server VoIP per replicare i dati direttamente nel data warehouse invece di utilizzare bucket di storage di oggetti cloud per sincronizzare i dati come abbiamo fatto inizialmente con myshipper. Quindi alla fine abbiamo deprecato myshipper, che abbiamo sviluppato nel 2019 per la replica dei dati dai nostri server VoIP, e abbiamo invece sfruttato le capacità di replica native di MariaDB.

Abbiamo anche iniziato ad aggiornare le nostre istanze del database Postgres da Postgres 10, che era prossimo alla fine del suo ciclo di vita , a Postgres 13. Per motivi di stabilità, abbiamo intenzionalmente deciso di non eseguire l'aggiornamento all'ultima versione (Postgres 14, quando la decisione di aggiornare è stato realizzato) ma, invece, aggiorniamo alla penultima versione che consideriamo più stabile perché è in circolazione da un po' più di tempo.

A causa del numero di istanze di Postgres 13 che dovevamo aggiornare e del coordinamento richiesto con le parti interessate dei sistemi a seconda di tali istanze di database durante la pianificazione e l'esecuzione dell'aggiornamento, alcune di esse devono essere riportate al 2023.

Per scopi di partnership, manteniamo alcuni server SFTP per lo scambio di dati poiché alcuni dei nostri partner ci richiedono di fornirli per scambiare rapporti con noi. Con l'aumentare del numero di partner che abbiamo, aumenta anche il numero dei nostri server SFTP. Per consentirci di gestire meglio i server SFTP su larga scala, abbiamo deciso di adottare SFTPGo con un bucket di archiviazione cloud come motore di archiviazione (invece di utilizzare i dischi VM cloud, che erano utilizzati nel nostro vecchio standard di configurazione SFTP).

Conclusione

Cinque anni non sono pochi e abbiamo ottenuto molto nei cinque anni trascorsi dalla concezione del nostro team della piattaforma infrastrutturale. L'architettura e il processo dell'infrastruttura si sono evoluti e maturati molto durante questi cinque anni.

I primi anni sono stati piuttosto brutali poiché il nostro ambito non era molto ben definito e avevamo bisogno di gestire molte cose che dovrebbero appartenere a un team separato mentre lavoravamo anche allo sviluppo dei domini dell'infrastruttura su cui dovremmo concentrarci, pur avendo solo due o tre persone nel team che lavorano per assicurarsi che tutto sia gestito durante il periodo di crescita della nostra azienda. Non è stato fino al 2020 che siamo finalmente riusciti a eliminare i domini che non dovrebbero essere l'obiettivo principale della nostra proprietà di dominio.

A partire dal 2020, abbiamo investito nell'assunzione di più manodopera per consentire una migliore distribuzione del carico di lavoro e abbiamo iniziato ad assumere ruoli più specializzati come amministratore di database e analista della sicurezza. Abbiamo anche iniziato ad assumere più ingegneri del software per aumentare la nostra velocità di sviluppo nello sviluppo della piattaforma e aggiungere più capacità per vari lavori di infrastruttura personalizzati che potremmo dover fare per supportare i lanci dei nostri prodotti.

Siamo decisamente in una posizione migliore ora rispetto a come era nel 2018 in termini di operabilità, sicurezza e affidabilità dei nostri sistemi infrastrutturali. È tutto grazie al duro lavoro di tutti i membri del team e di coloro che ci hanno supportato durante tutto il processo.