Clonare l'immagine di un server VPN senza clonarne l'identità

L'immagine si avvia, il servizio parte e i client si connettono. È il momento di fermarsi e chiedersi quale delle due operazioni molto diverse sia appena avvenuta. O la copia ripristina un gateway logico che esisteva già, oppure aggiunge un secondo gateway alla flotta. Entrambe sono legittime e hanno conseguenze diverse per identità e accesso. Una macchina che si avvia in modo pulito non prova nessuna delle due.

Tre condizioni decidono la risposta, e sono i tre contenitori di materiale che un'immagine può portare. Ordinali prima che l'immagine sia costruita, non dopo che è stata distribuita due volte.

Decidete prima quale delle due operazioni state eseguendo

Un ripristino conserva una sola identità di servizio. La vecchia istanza è sparita, il nome e il certificato restano, e i client continuano a fidarsi dello stesso endpoint. Un'aggiunta crea una seconda identità che client, registri e revoca devono tutti distinguere.

La distinzione non è cosmetica. Se due host attivi presentano lo stesso certificato di gateway, un client non può distinguerli, e nemmeno una traccia di controllo, e revocare quel certificato li rimuove entrambi insieme. Può essere esattamente ciò che vuole un progetto deliberato ad alta disponibilità, ed è raramente ciò che intende una copia affrettata di un'immagine.

Quindi la prima decisione è una frase, scritta prima che l'immagine lasci l'host di build: questa copia ripristina il gateway A, oppure questa copia diventa il gateway B. Tutto il resto è contabilità rispetto a quella frase. Se nessuno riesce a scriverla, la copia non è pronta per essere costruita.

Input riutilizzabili, identità e autorità, stato di distribuzione

Il contenitore riutilizzabile è quello facile: pacchetti, configurazione rivista che non contiene segreti, modelli di servizio, impostazioni di irrobustimento. È ciò in cui un'immagine è davvero brava, e può essere riprodotta senza limite.

Il contenitore di identità e autorità è dove le copie sbagliano. La chiave privata e il certificato di un gateway identificano quel gateway presso ogni client. La chiave di firma dell'autorità di certificazione è un oggetto diverso con un potere diverso: emette identità. Fidarsi di un emittente non significa che ogni nuovo gateway abbia bisogno della capacità di emettere, e spedire la chiave di firma dentro un'immagine concede quella capacità a qualunque cosa possa leggere l'immagine.

Il contenitore dello stato di distribuzione è quello che la gente dimentica perché sembra configurazione. Gli indirizzi di ascolto, i pool di indirizzi, le rotte spinte, le impostazioni del resolver e l'integrazione locale codificano tutti assunzioni sul primo host. Un secondo nodo che le copia può assegnare da un pool che un altro gateway possiede già, o indirizzare i client verso una risorsa che esiste solo accanto all'originale.

Cosa deve ricevere un nuovo nodo, e da chi

Un nodo gestito in modo indipendente dovrebbe ricevere le proprie credenziali tramite il processo di registrazione approvato, con l'operazione di firma che avviene dove vive la chiave di firma e non sul nuovo host. Annotate quale identità può essere ritirata senza disturbare gli altri nodi; se la risposta è "tutte", il progetto ha un'identità che finge di essere due.

I valori di rete meritano lo stesso trattamento. Scegliete un pool, un indirizzo di ascolto e un insieme di rotte spinte che non entrino in collisione con il gateway esistente, e scriveteli negli input di provisioning invece che nell'immagine. L'input è verificabile; l'immagine no.

Esiste un caso intermedio legittimo. Un progetto di ripristino o replica supportato può mantenere deliberatamente una sola identità logica di servizio tra host, con accesso controllato alla vecchia copia e un piano di rotazione. È una decisione con un proprietario, non un'impostazione predefinita che accade perché l'immagine era comoda.

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

Il primo comando dice quale identità il nodo presenta davvero e chi l'ha firmata. Il secondo è un inventario iniziale, non una prova: il materiale privato può vivere fuori da quella directory, dentro un database applicativo o in uno strato di snapshot che il filesystem in esecuzione non mostra più.

Cosa porta silenziosamente una copia dell'immagine

Eliminare un file dalla revisione più recente di un'immagine non lo rimuove dalle revisioni precedenti, dalle cache dei livelli o dagli snapshot presi mentre esisteva. Per questo le immagini che portano credenziali vanno trattate come oggetti sensibili per tutta la loro vita, non solo nel momento in cui vengono costruite.

Verificate il contenuto dell'immagine e gli input di provisioning come domande separate. L'immagine risponde a "cosa c'è dentro questo artefatto", mentre gli input rispondono a "cosa diventerà questa istanza al primo avvio". Un'immagine pulita con uno script di avvio che recupera una chiave condivisa risponde bene alla prima domanda e male alla seconda.

Tenete le immagini di ripristino che contengono legittimamente segreti limitate alle persone che ne hanno bisogno, e annotate dove sono conservate. L'alternativa, un'immagine comoda perché funziona senza alcun provisioning, è la stessa immagine che concede l'identità del gateway a chiunque la trovi. Solo una di queste due attività compare in un registro di build.

Controlli di ammissione prima della produzione

Prima che il nodo accetti traffico, confermate quattro cose: l'identità che presenta, i client che accetterà, le risorse a cui gli è consentito arrivare e il percorso di ritorno per gli indirizzi che distribuisce.

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

Poi verificate il caso negativo, quello che intercetta gli incidenti: il nuovo nodo ha un accesso amministrativo o client che era destinato all'originale? Una configurazione copiata può portare una voce client in più, una rotta di gestione ereditata o una direttiva push che aveva senso sul primo host.

Se un'immagine con segreti attivi ha già superato il proprio limite approvato, sostituite le credenziali e contenete le copie. Rimuovere il file dall'ultima build non è la stessa cosa che mettere fuori servizio la credenziale che le copie più vecchie detengono ancora, e lo scarto tra questi due fatti è esattamente la finestra di cui ha bisogno un attaccante.