Blocklist di Nebula: distribuirla, il faro non lo farà

L’applicazione della blocklist è una proprietà dell’host che esegue il controllo, non del certificato controllato. Una macchina che non ha mai caricato la voce continua ad accettare l’identità, e nulla nell’handshake avverte che due peer sono in disaccordo. La correzione economica e quella costosa per una stessa credenziale esposta differiscono per portata e reversibilità, quindi scegli deliberatamente. Le sezioni seguenti spiegano cosa fa la voce, dove deve essere consegnata, quando la rotazione è la risposta migliore e come dimostrare che una delle due ha funzionato.

Cosa fa davvero una voce della blocklist

La configurazione PKI elenca le impronte che un host deve rifiutare anche se il certificato è firmato validamente e non scaduto. L’applicazione avviene localmente, rispetto all’elenco che quell’host ha caricato all’avvio del servizio. Nulla della voce viaggia dentro il certificato, quindi un peer non può apprendere la decisione dalla credenziale che gli viene mostrata. Ecco perché un faro non ha alcun ruolo qui: i fari aiutano i peer a trovarsi e a inoltrare il traffico dove un percorso diretto fallisce. Sono uno strato di scoperta e inoltro, non un canale di distribuzione della configurazione.

Aggiornare una macchina cambia le decisioni di quella macchina e lascia ogni altro peer esattamente com’era. Un peer che si fida dell’autorità di firma e non ha mai visto la voce non ha motivo di rifiutare nulla. Testare la revoca osservando il faro non dimostra quindi nulla, perché al componente che stai osservando non è mai stato chiesto di applicare l’elenco.

Identifica il certificato, non il dispositivo

Usa l’impronta della credenziale che intendi rifiutare, perché un nome host, un’etichetta del dispositivo o un indirizzo attuale identificano una macchina oggi e qualcos’altro il mese prossimo. Nessuna di queste stringhe compare nella blocklist e nessuna sopravvive a una reinstallazione. Stampa il certificato, leggi l’impronta e verifica che appartenga alla credenziale in dismissione e non al suo sostituto. Leggere entrambi i file conta quando un sostituto è già stato emesso, poiché il certificato vecchio e quello nuovo possono condividere il nome e differire in ogni altro campo.

Registra quale impronta è stata bloccata e quando, così un controllo successivo distingue una modifica completata da una prevista. Annota anche ciò che la voce non fa: non invalida l’autorità di firma e non impedisce che un futuro certificato di quell’autorità venga accettato. Bloccare un certificato host e sostituire un’autorità compromessa sono operazioni diverse con conseguenze diverse.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

Distribuirla come qualsiasi altra configurazione

Tratta l’elenco come configurazione con un meccanismo di consegna, non come un file che qualcuno modifica quando se ne ricorda. Invia l’elenco intero invece di un delta, così un host che ha perso un aggiornamento precedente si allinea invece di accumulare lacune. La documentazione PKI di Nebula consiglia esattamente questo, e vale la pena seguire il consiglio alla lettera invece di parafrasarlo in una procedura manuale.

Conferma che il servizio in esecuzione abbia ricaricato il contenuto, non solo che il file su disco sia cambiato. Tieni traccia delle macchine che hanno applicato la modifica e mantieni visibile l’elenco delle rimanenti finché non è vuoto. Un portatile chiuso per una settimana è un peer che non ha mai appreso la decisione e può ricollegarsi da una rete che nessuno si aspettava. Registra il metodo di consegna accanto all’impronta, perché la revoca successiva lo riutilizza ed è sulla prima che si esegue il debug della procedura.

Blocklist o rotazione dell’autorità

Una voce della blocklist è ristretta: un’identità smette di funzionare e tutto il resto continua. La rotazione dell’autorità di firma è ampia: ogni certificato emesso diventa inaffidabile e ogni host necessita di una nuova credenziale e di una nuova ancora di fiducia. La prima è una revoca mirata e la seconda è una migrazione, quindi richiedono approvazioni diverse e finestre di manutenzione diverse. La tabella le mette a confronto su portata, impegno e reversibilità.

Un portatile smarrito richiede la blocklist, perché il raggio d’azione è un’identità e la modifica è reversibile se hai bloccato l’impronta sbagliata. Una chiave di autorità trapelata richiede la rotazione, perché la blocklist non può aiutare con certificati non ancora emessi. Tra questi estremi, chiediti se la credenziale esposta avrebbe potuto firmare qualcos’altro, dato che un’autorità è più di un host.

Scrivi la decisione prima di un incidente, perché scegliere sotto pressione tende a produrre l’opzione ampia per impostazione predefinita. Qualunque strada intraprendi, l’elemento di lavoro rimanente è identico: dimostrare che l’applicazione è avvenuta sugli host che contano. Registrare l’impronta e la data in quel momento è ciò che rende possibile la prova in seguito.

Verifica il rifiuto e il resto

Connettiti dall’identità bloccata e conferma l’errore, poi connettiti da un peer autorizzato e conferma che raggiunge ancora ciò che gli serve. Una modifica che rompe tutto non è una revoca riuscita. Fai entrambe le cose da sessioni nuove, perché lo stato in cache può nascondere il risultato.

Controlla se una sessione stabilita termina dopo la modifica e annota il comportamento per la tua versione e configurazione invece di dare per scontato che modificare un file termini qualcosa. L’opzione disconnect_invalid copre i client i cui certificati sono scaduti o non validi, quindi conferma come si applica al tuo caso prima di farvi affidamento. Se la chiusura immediata è un requisito, testala specificamente e registra ciò che hai osservato. Poi ripeti il test dopo un riavvio, perché un host che applica l’elenco solo fino al riavvio successivo ha un problema di consegna che il primo test ha nascosto. Un faro sano ti dice che la scoperta funziona, non che un peer abbia applicato una politica.