Profilo OpenVPN in Git: cosa rimuovere prima di eseguire il commit

I profili svolgono due funzioni insieme: registrano le impostazioni di connessione e trasportano un pacchetto di credenziali che funziona. L'estensione del file non ti dice nulla su quale delle due cose hai in mano. Leggi il contenuto prima di decidere che appartiene a un repository.

I passaggi seguenti presuppongono che si stia valutando un modello client per il controllo di versione. Eseguili in ordine e fermati prima di eseguire il commit di qualcosa che non puoi revocare.

Leggi il file che stai per preparare

Parti dai byte reali, perché un profilo che fa riferimento a file separati è molto diverso da uno che li incorpora. Cerca i marcatori di blocco PEM e i tag inline chiamati ca, cert, key, tls-auth e tls-crypt, e la stessa passata ti mostrerà entrambi i casi. Una chiave privata cifrata conta comunque come materiale sensibile, e una chiave tls-auth o tls-crypt condivisa è una credenziale anche se non è l'identità di un utente. Applica la stessa revisione a tutto ciò che viene preparato accanto al profilo, inclusi archivi e script di installazione che fanno riferimento a un file di credenziali.

Poi guarda l'insieme preparato invece dell'albero di lavoro. git diff --cached mostra cosa conterrà davvero il commit, ed è l'unica versione che conta per questa decisione.

Decidi cosa il repository può distribuire

Un modello può trasportare le impostazioni condivise e riviste e segnaposto denominati per tutto ciò che una persona riceve al momento dell'iscrizione. Ciò che non può trasportare è un'identità utilizzabile, perché un repository distribuisce a tutti coloro che possono leggerlo, automazione inclusa. Un repository privato restringe il pubblico senza cambiare la domanda se ogni lettore sia autorizzato per quella credenziale.

Una regola di esclusione impedisce aggiunte future e non fa nulla per ciò che è già registrato. Vale la pena interiorizzare questa asimmetria prima del primo commit e non dopo il decimo. I nomi e gli indirizzi dell'infrastruttura sono un giudizio a parte: non sono segreti di autenticazione, ma possono rivelare più di quanto un team intenda pubblicare. Prendi quella decisione in modo esplicito invece di classificare ogni riga in password o pubblico.

Se il materiale è già nella cronologia

Rimuovere la riga in un nuovo commit lascia la vecchia versione intatta per chiunque la scarichi. Tratta l'esposizione come reale: identifica il tipo di credenziale, poi trova l'autorità che può invalidarla. Il certificato client viene revocato e la lista di revoca rigenerata; una chiave condivisa del canale di controllo viene sostituita sul server e su ogni client che la usa.

Le due hanno raggi d'azione molto diversi, e il piano deve indicare quale stai eseguendo prima di iniziare. Individua il commit che ha introdotto il materiale con una ricerca del tipo git log --all -S 'BEGIN PRIVATE KEY', così che l'ambito della pulizia sia noto e non ipotizzato. Il clone di un collega o un fork può già contenere il vecchio oggetto, per questo la revoca viene prima e la pulizia dopo.

Pulisci solo dopo averlo contenuto

Riscrivere la cronologia cambia ogni commit successivo a quello che modifichi, quindi serve prima l'accordo del proprietario del repository e delle persone che ci lavorano. Un push forzato non è una riparazione; è un evento di coordinamento con il proprio rischio di rollback. Pianificalo, fai un backup e dì al team quando avverrà.

Dopo, verifica l'albero attuale e la cronologia rimanente invece di fidarti del riepilogo dello strumento.

Conserva il risultato come due artefatti: il modello sicuro da condividere e l'inventario delle credenziali emesse durante il processo di iscrizione. Nessuno dei due richiede che un'identità utilizzabile viva nel repository.

Questa separazione è la vera soluzione, e sopravvive alla prossima persona che vorrà eseguire il commit di un profilo.