La trappola delle due tailnet: una chiave vecchia che ha modificato la rete sbagliata
I clienti raggiungono il loro Mac a noleggio tramite Tailscale. Teniamo la regola di accesso SSH nella policy della tailnet, e la gestiamo dal codice. Quando inizia un noleggio, l’indirizzo del cliente viene aggiunto. Quando finisce, viene rimosso. È un sistema piccolo e noioso. Poi ci ha detto che ogni cliente aveva perso l’accesso, e stava mentendo.
Cosa ha segnalato lo strumento
Un controllo di routine ha annunciato che la regola SSH dei clienti era vuota. Secondo lui, tre clienti paganti non potevano più collegarsi. Per un’azienda il cui prodotto è l’accesso a una macchina, è un allarme di massimo livello.
La regola non era vuota. Stavamo leggendo un’altra tailnet.
Due reti, un alias
L’account aveva due tailnet. Una contiene la flotta: i Mac a noleggio, l’hub, ogni condivisione con i clienti. L’altra era una vecchia rete personale rimasta dal setup, con una macchina spenta e un portatile.
L’API di Tailscale ti permette di indicare una tailnet per nome, oppure di passare -, che significa "la tailnet della chiave che fa la chiamata". Il nostro codice passava -. Va bene finché le chiavi non diventano due. Le chiavi sono stringhe indistinguibili, quindi - segue in silenzio quella presente nell’ambiente. Una chiave vecchia si era infilata in un file di configurazione.
La parte pericolosa era la scrittura
Una lettura che mente fa perdere un pomeriggio. Una scrittura che mente causa un incidente. Lo stesso strumento ha una modalità di riparazione che allinea la regola di accesso ai clienti attuali. Eseguita sulla tailnet sbagliata, ha scritto fedelmente gli indirizzi email di tre clienti reali nella policy della vecchia rete, dove non facevano assolutamente nulla.
Nessun cliente è stato davvero colpito, perché la tailnet della flotta è rimasta intatta e corretta per tutto il tempo. Ma per qualche minuto l’automazione ha modificato il controllo degli accessi sulla rete sbagliata, segnalando successo.
La soluzione: indicare la rete per nome
Abbiamo smesso di passare -. Ora il codice indica la tailnet della flotta per nome. Una chiave che non la vede fallisce in modo evidente, invece di finire su qualsiasi rete riesca a vedere.
Ora ogni esecuzione stampa la tailnet con cui ha parlato. Se quella riga non è la flotta, i risultati sotto non significano nulla, e lo sai prima di agire.
La lezione generale
Un default comodo che significa "qualsiasi cosa indichi questa credenziale" diventa una trappola appena hai più di una credenziale. Trasforma una chiave sbagliata da errore a reindirizzamento silenzioso. Tutto ciò che scrive dovrebbe indicare il suo target. Così usare la credenziale sbagliata fallisce, invece di riuscire da qualche parte dove non volevi.
È la stessa forma degli altri guasti silenziosi che abbiamo raccontato in controlli che non possono fallire. Lo strumento era sicuro di sé. Lo strumento sbagliava. E niente di ciò che stampava te lo avrebbe detto, finché non ha indicato la rete che stava modificando.
Domande
- Come fa una chiave API di Tailscale a scegliere quale tailnet modificare?
- La chiave appartiene a una tailnet, e nell’API il nome di tailnet '-' significa 'la tailnet di questa chiave'. Due chiavi per due tailnet sembrano identiche, quindi '-' segue la chiave in silenzio.
- Come si distinguono due tailnet in modo sicuro?
- Mai a occhio. Confronta quali dispositivi vede ciascuna chiave. La chiave giusta vede la tua flotta. Quella sbagliata vede qualsiasi altra cosa possieda quell’account.
- Gli strumenti dovrebbero mai usare l’alias di tailnet '-'?
- Non per qualcosa che scrive. Indica la tailnet per nome, così una chiave della rete sbagliata fallisce con un 404 invece di modificare in silenzio l’ACL sbagliata.
Fai i tuoi conti con il calcolatore oppure noleggia un runner.