OpenTofu o Terraform: la cifratura dello state rompe la simmetria

OpenTofu offre una differenza concreta a chi vuole cifrare state e plan prima che raggiungano il backend. La cifratura configurabile di OpenTofu protegge il contenuto di una copia dello state conservata nel backend, ma senza la chiave corretta rende il file irrecuperabile. È una ragione per sceglierlo solo se il team sa custodire e recuperare quella chiave.

Terraform può restare la scelta più semplice dove backend e servizi gestiti soddisfano già i requisiti. La guida di Terraform ai dati sensibili spiega che la cifratura dello state a riposo dipende dal backend e distingue i valori sensitive, ancora presenti nello state, dai valori ephemeral e dagli argomenti write-only, esclusi nei contesti supportati. La decisione riguarda quindi anche quali dati vengono salvati e chi può accedere all’ambiente di esecuzione.

Dove cambia la protezione dello state

Con la cifratura attivata in OpenTofu, il client cifra lo state prima di consegnarlo al backend; può applicare la protezione anche ai plan. Una persona che ottiene soltanto il file archiviato non ne legge così i valori sensibili senza la chiave. La persona o la pipeline che esegue OpenTofu con accesso alla chiave continua invece a vedere i dati necessari al lavoro: restano indispensabili permessi, controllo delle credenziali e protezione dei backup.

Terraform affronta parte del problema da un altro lato. Marcare un valore come sensitive lo nasconde nell’output ordinario, ma non lo elimina dallo state o dal plan. Un valore ephemeral può evitare quella persistenza, purché sia usato in un contesto consentito; gli argomenti write-only dipendono dal supporto del provider. La cifratura offerta da un backend remoto protegge il file conservato, mentre la scelta di non registrare un segreto riduce i dati che il file contiene.

Compatibilità del codice e reversibilità dello state

Molte configurazioni HCL, moduli e provider restano utilizzabili passando da Terraform a OpenTofu. La compatibilità va però verificata sul progetto concreto: vincoli di versione, funzioni introdotte dai due strumenti e automazioni che invocano un eseguibile specifico possono cambiare il risultato. Un plan senza modifiche inattese è una prova più utile della sola riuscita di init, soprattutto quando più configurazioni si scambiano output tramite terraform_remote_state.

Per il rollback conta soprattutto quale state è disponibile. I casi hanno costi diversi:

• Cambio del solo eseguibile: una copia dello state precedente offre un punto di ritorno, a condizione che Terraform riesca ancora a leggere configurazione e formato salvato. Il confronto dei plan mostra se il ritorno è praticabile senza modificare risorse.
• State cifrato, chiave disponibile: OpenTofu deve leggere il file e riscriverlo senza la propria cifratura prima che Terraform possa usarlo. La transizione richiede accesso alla chiave e una gestione controllata della copia non cifrata.
• State cifrato, chiave perduta: il backup del solo file cifrato non ripristina l’accesso. Serve la chiave, oppure una copia precedente dello state ancora leggibile; quest’ultima può richiedere di riconciliare le modifiche avvenute nel frattempo.

Il costo di una chiave persa non è un sovrapprezzo fisso: è il tempo necessario a ristabilire una rappresentazione affidabile delle risorse prima di pianificare altre modifiche. Dipende dall’età dei backup, dalle modifiche successive e da chi può recuperare le credenziali. Anche la rotazione delle chiavi va considerata: cambiare metodo o chiave richiede una transizione che mantenga disponibile il metodo precedente finché lo state non è stato riscritto.

Licenza ed ecosistema gestito

La licenza del repository OpenTofu è la Mozilla Public License 2.0. Per Terraform, le precisazioni di HashiCorp sulla Business Source License consentono l’uso interno, anche in produzione, e circoscrivono la restrizione alle offerte competitive verso terzi che incorporano o ospitano il prodotto. Per un’azienda che gestisce la propria infrastruttura e per chi vende una piattaforma IaC, la stessa licenza pone dunque questioni diverse.

La compatibilità di un modulo non trasferisce automaticamente il servizio che lo esegue. Un’organizzazione che usa esecuzioni remote, registro privato, policy e autorizzazioni in HCP Terraform deve valutare dove svolgere quelle funzioni dopo un’eventuale migrazione. Nel costo entrano configurazione della pipeline, gestione delle identità, conservazione dello state e procedure di intervento. Se il flusso gestito è già essenziale per i rilasci, sostituire il comando rappresenta solo una parte del lavoro.

Che cosa mostra il test su risorse locali

Nel benchmark di TechPlained su 400 risorse locali, costruite con i provider random, local e null, init con provider già in cache richiede 1.694 millisecondi con Terraform 1.16.1 e 392 con OpenTofu 1.12.6. Il rapporto è circa 4,3 e la differenza è 1.302 millisecondi per quell’operazione, su quella configurazione. Il risultato misura la combinazione di eseguibile, provider, cache e macchina del test; non isola una proprietà universale del solo motore.

Le risorse locali eliminano le chiamate alle API cloud durante plan e apply e rendono più visibile il tempo impiegato dal lavoro locale. Una misura su risorse AWS dello stesso confronto riguarda invece un ambiente in cui rete e servizio remoto pesano molto di più. Le due osservazioni rispondono a domande diverse: il vantaggio di init a caldo può incidere in una pipeline che lo ripete spesso, mentre non permette di prevedere con lo stesso rapporto la durata del provisioning cloud. Il test non comprende inoltre la latenza di un backend remoto.

Una prova di migrazione che comprenda il recupero

La prova più informativa separa il cambio di eseguibile dall’attivazione della cifratura. Si conservano prima codice, lock file e snapshot dello state, impedendo scritture concorrenti durante la verifica. In un ambiente isolato si eseguono init e plan con OpenTofu, si confrontano le modifiche previste con quelle di Terraform e si controllano le configurazioni che leggono state remoti. Solo dopo si introduce la cifratura nella prova.

1. Conservare lo snapshot precedente in uno spazio con accesso limitato. Stabilire dove saranno custodite la chiave e le informazioni necessarie a usarla, comprese le autorizzazioni del servizio di gestione delle chiavi se presente.
2. Per uno state esistente, configurare la transizione esplicita dal metodo unencrypted al metodo cifrato. Attivare la protezione, verificare che OpenTofu legga il nuovo snapshot e rimuovere il fallback non cifrato quando la transizione è completata.
3. Su una copia isolata, revocare temporaneamente l’accesso alla chiave e accertare che la lettura fallisca. Ripristinare l’accesso con la procedura prevista e verificare che lo stesso snapshot torni leggibile.
4. Provare il ritorno a uno state non cifrato mentre la chiave è ancora disponibile, poi verificare che Terraform legga la copia risultante e produca un plan coerente. Questa prova distingue il recupero dello state dalla compatibilità del codice.

Il criterio decisivo è che backup e chiave siano recuperabili anche quando la persona o la pipeline abituale non è disponibile. Se la prova fallisce, il team conosce prima della migrazione il punto da correggere: custodia della chiave, autorizzazioni o procedura di ripristino. La cifratura offre una protezione aggiuntiva solo insieme alla capacità operativa di accedere ancora allo state quando serve.