GitLab per gli aggiornamenti in produzione: workflow sicuri per l'industria manifatturiera

Il punto di partenza è una domanda ricorrente nei reparti IT/OT: come aggiornare il software di fabbrica in modo ripetibile, tracciabile e reversibile, senza fermare le linee e senza sorprese?

La risposta proposta è trattare ogni aggiornamento come una release gestita in pipeline. La documentazione ufficiale di GitLab riconosce che i job di deploy possono essere più sensibili degli altri job di una pipeline e richiedere maggiore cautela. Per questo la piattaforma offre funzioni dedicate alla sicurezza e alla stabilità dei rilasci.

In ambito industriale un aggiornamento sbagliato può costare fermi di linea o in alcuni casi anche rischi per la sicurezza fisica. Il NIST, imposta la sicurezza OT tenendo presenti i requisiti specifici di prestazioni, affidabilità e sicurezza (safety) di questi sistemi. Anche lo standard IEC TR 62443-2-3 sulla gestione delle patch descrive sia lo scambio di informazioni sulle patch tra asset owner e fornitori, sia le attività di distribuzione e installazione a carico dell'asset owner.

I vantaggi concreti di una pipeline GitLab, per come li leggiamo, sono quattro:

• Fonte unica di verità: codice, configurazioni e definizione del rilascio vivono nello stesso repository, con storico e revisioni.
• Controllo degli accessi sul deploy: gli ambienti protetti limitano chi può distribuire e, nei piani superiori, richiedono approvazioni esplicite.
• Reversibilità: il rollback è una funzione prevista dalla piattaforma, non un'improvvisazione.
• Funzionamento in reti isolate: una istanza self-managed può operare con connettività limitata o assente, a patto di gestire gli aggiornamenti dei componenti in modo offline.

Ambienti protetti e approvazioni

La documentazione spiega che, poiché i job di deploy possono essere lanciati da utenti con ruoli diversi, serve poter proteggere ambienti specifici dagli effetti di utenti non autorizzati. Per proteggere o modificare un ambiente serve almeno il ruolo Maintainer. È inoltre possibile indicare il numero di approvazioni richieste per distribuire in quell'ambiente.

GitLab permette di impostare un deploy freeze: durante il periodo di blocco, tutti i deploy vengono fermati. Per un reparto produttivo è un modo naturale per codificare i periodi in cui non si tocca nulla, come picchi di produzione, audit o collaudi. Esiste anche un rischio meno ovvio, descritto nella documentazione: se la pipeline B, più recente, termina prima della A, la A può distribuire codice più vecchio sovrascrivendo l'ultimo rilascio. La guida spiega come evitarlo con le opzioni sui deploy obsoleti. Per impedire deploy concorrenti sullo stesso ambiente si usano i resource group: il job della seconda pipeline attende la fine del primo.

Canary. La documentazione GitLab definisce il canary come una strategia in cui una piccola parte della flotta viene aggiornata per prima alla nuova versione. Il supporto descritto si appoggia a Kubernetes e a un Canary Ingress. In fabbrica, dove spesso non c'è Kubernetes, il principio si traduce (è una nostra trasposizione, non una funzione documentata) in un aggiornamento su una sola cella, una sola linea o un solo nodo edge prima del resto.

Rollback. Secondo la documentazione, il rollback su un commit crea un nuovo deploy. Perché funzioni, il processo di deploy deve essere definito nello script del job. Se serve rigenerare artefatti prodotti da job precedenti, quei job vanno rilanciati a mano.

Reti isolate. GitLab pubblica un tutorial sulla scansione di sicurezza in ambienti air-gapped. Ricorda che anche i sistemi isolati possono avere vulnerabilità. Il procedimento prevede di trasferire le immagini degli scanner nell'ambiente offline e caricarle in un registry offline.

Percorso pratico

Ecco un percorso in otto passi. L'ordine e la sua applicazione allo specifico impianto sono una mia proposta.

1. Censite e classificate le applicazioni. Fate un inventario di cosa si aggiorna, su quali macchine e con quale criticità. Lo standard IEC chiede un programma formale di patch management, con ruoli sia per l'asset owner sia per i fornitori. Stabilite chi decide e chi esegue.
2. Portate tutto in Git. Codice, configurazioni, script di deploy e definizione della pipeline vanno nel repository. Proteggete il ramo principale e i tag di release. Valutate un progetto separato per i deploy e la protezione del file .gitlab-ci.yml, entrambi indicati nella pagina sulla sicurezza dei deploy.
3. Replicate gli ambienti. Prevedete almeno sviluppo, staging (idealmente con le stesse versioni e configurazioni della produzione) e produzione. La produzione va dichiarata come ambiente protetto, con elenco esplicito di chi può distribuire.
4. Separate chi scrive da chi approva. Con le approvazioni di deploy, configurate almeno un responsabile di produzione e uno di sicurezza o qualità. Verificate che il numero di approvazioni richieste sia coerente con le persone abilitate.
5. Bloccate i deploy concorrenti e quelli obsoleti. Usate i resource group, disattivate i retry dei job di rollback nei progetti sensibili e definite le finestre di deploy freeze coerenti con il calendario di produzione.
6. Procedete per gradi. Prima una cella pilota, poi una linea, poi l'intero stabilimento. Dove c'è Kubernetes potete usare il canary di GitLab; altrimenti replicate la logica con job manuali separati per ogni gruppo di macchine.
7. Scrivete e provate il rollback prima del deploy. Verificate che il job di deploy contenga tutto il necessario e che gli artefatti richiesti siano disponibili. Il rollback va provato in staging, e se l'impianto è isolato va provato anche senza accesso a internet. Ricordate che il rollback del solo software non annulla eventuali modifiche ai dati o agli schemi: per quelli serve un piano a parte.
8. Isolate l'infrastruttura e verificate dopo il rilascio. In rete segmentata o air-gapped, tenete runner, registry e mirror dei pacchetti dentro il perimetro. Gestite offline anche gli aggiornamenti di GitLab e degli scanner di sicurezza. Dopo ogni deploy, controllate versioni, stato dei servizi e metriche di processo e archiviate l'evidenza: serve per gli audit e per la prossima release.

Errori frequenti da evitare: staging diverso dalla produzione, segreti di produzione accessibili a tutti i job, rollback mai provato, finestre di manutenzione non codificate e aggiornamenti dell'istanza GitLab stessa fatti senza test (in OT è anch'essa un'applicazione critica). Un limite pratico: in ambienti isolati la gestione di runner, registry, backup e upgrade ricade interamente sul vostro team.

Fonti

• GitLab Docs – Deployment safety
• GitLab Docs – Deployments (rollback)
• GitLab Docs – Canary deployments
• GitLab Docs – Protected environments
• GitLab Blog – Tutorial: Security scanning in air-gapped environments
• IEC TR 62443-2-3:2015 – Patch management in the IACS environment
• NIST – Guide to Operational Technology (OT) Security, SP 800-82r3