Un token è facile da creare e facile da dimenticare, ed è dalla dimenticanza che nascono le interruzioni. Chi ne possiede uno, cosa fa la sua scadenza a un job che nessuno guarda, cosa succede quando il proprietario se ne va, e come ruotarne uno senza interruzioni.
Aggiornato · 7 min di lettura
Un token di accesso personale viene emesso a una persona con un nome, a suo nome, e porta esattamente i permessi Tableau che quella persona già ha. È questo che lo rende adatto a costruirci sopra un confine di governance: qualsiasi cosa fatta con esso è qualcosa che il proprietario avrebbe potuto fare comunque, e ogni riga di audit a valle porta onestamente il suo nome.
Rende anche il token un oggetto amministrativo, non tecnico. Ha un proprietario, il proprietario ha un team, e il team ha una turnazione. Quasi ogni cosa scomoda in questa pagina discende da questo unico fatto.
Il primo artefatto che vale la pena avere è un registro: una riga per token, con il job che alimenta, la persona che ne risponde, dove è conservato, e la data in cui scade. Quattro righe richiedono dieci minuti e rispondono alla domanda che altrimenti richiede una mattinata, cioè: se revoco questo, cosa si ferma.
Tableau Cloud consente una sola sessione attiva per token. Ogni nuovo accesso con quel token termina la sessione precedente, il che è comodo finché lo usa una persona sola e scomodo nel momento in cui lo usano due cose.
La suite è costruita intorno a quel comportamento invece che contro. Il gateway accede una volta, conia una singola sessione Tableau, e consegna quell’unica sessione a ogni strumento. Gli strumenti la condividono invece di accedere ciascuno di nuovo con lo stesso token e invalidare l’accesso precedente.
La stessa regola dà forma al comportamento di un job lungo. Prima che un’esecuzione di migrazione da una sorgente Cloud venga approvata, l’anteprima preliminare lo dice a chiare lettere: usa un token dedicato a questa esecuzione, con un nome che nient’altro usa, e assicurati che nessuna pianificazione, scheda del browser o secondo dispositivo lo condivida. L’esecuzione ritenta i fallimenti di autenticazione in tornate distanziate: una collisione è sopportabile, ma un client che continua a riaccedere con lo stesso token lo affamerà comunque. Una sorgente Server tollera sessioni concorrenti su un token, ed è per questo che un’abitudine innocua per anni può sorprendere un team alla sua prima esecuzione Cloud.
Un job pianificato e una persona che sembrano interferire tra loro di solito sono questo, e si presenta come instabilità intermittente del prodotto, raramente come il problema di credenziali che è. Controlla quale token ha in mano ciascuna parte prima di indagare qualsiasi altra cosa.
Un token ha una scadenza, e un’automazione costruita sopra eredita quella data senza mai menzionarla di nuovo. Il guasto arriva quindi alla successiva esecuzione pianificata invece che al momento della scadenza. Il divario tra la morte del token e il momento in cui qualcuno ne sente parlare è una cadenza intera. Su un job mensile, è un mese.
Due impostazioni vale la pena leggerle sul tuo sito, non darle per scontate: la scadenza che un amministratore ha impostato quando il token è stato emesso, e qualunque cosa il tuo sito faccia con un token rimasto inutilizzato. Un token che alimenta un job trimestrale passa la maggior parte della sua vita inattivo, che è la combinazione che coglie i team di sorpresa.
Dove un’esecuzione pianificata può ripiegare dal token personale a una credenziale di servizio, la risposta progettuale è piccola ma decisiva: quale credenziale ha davvero autenticato viene registrato sull’esecuzione e mostrato sulla riga. Senza quel record, un ripiego silenzioso resta non riparato, e il problema emerge solo quando fallisce anche il ripiego.
Un’esecuzione fallita arma comunque la successiva: una pianificazione che smette di avanzare resta permanentemente dovuta, e il runner continua a cercarla.
L’account se ne va e il token con lui. È il comportamento corretto, ed è anche il momento in cui diversi job non presidiati si fermano tutti insieme senza che nessuno di essi compaia nella lista di uscita.
Una persona su un sito Tableau può possedere sei tipi di cose: cartelle di lavoro, origini dati pubblicate, flussi, progetti, sottoscrizioni e attività di aggiornamento. I suoi token sono un settimo, e a differenza degli altri sei un token non compare in nessun albero di progetti. Occupatene nella stessa ora in cui ti occupi dei contenuti che possiede, o una pianificazione lo troverà per te.
L’offboarding e l’igiene dei token sono la stessa disciplina vista dai due estremi. Un registro che nomina la persona responsabile di ogni token trasforma la conversazione di uscita in una ricerca invece che in un’indagine.
La rotazione va male quando viene fatta come uno scambio. Fatta come una sovrapposizione, passa senza eventi.
Il passo di installazione è sicuro da eseguire mentre il lavoro è in corso. Una credenziale bloccata viene scritta in un file temporaneo e poi spostata al suo posto, così un’esecuzione che parte a metà rotazione legge o la vecchia credenziale o la nuova e mai metà di un file.
Il passo tre è quello che le persone saltano, ed è l’unico passo che prova qualcosa. Se l’esecuzione riesce con la credenziale di servizio, il token personale è già rotto, la rotazione non ha testato nulla, e hai appena revocato la tua prova.
Dove un token è bloccato da un amministratore per un deployment ospitato, il controllo di disconnessione è deliberatamente nascosto, perché il caricamento di pagina successivo lo riconnetterebbe comunque. Quella credenziale si cambia invece nella console di amministrazione, che è dove chiunque la cerchi penserà di guardare.
I segreti in questa suite durano solo per la sessione, il che regge bene finché un job non deve girare alle due e mezza senza nessuno. L’eccezione è esplicita, ristretta, e vale la pena capirla prima di farci affidamento.
Una riga in quell’elenco fa più lavoro di quanto sembri. Il sito a cui punta una pianificazione viene impresso lato server dalla sessione attiva, mai letto dalla richiesta, perché un chiamante in grado di impostarlo potrebbe puntare un’esecuzione pianificata a un sito diverso mentre tiene la credenziale di qualcun altro.
È tutto ordinario. È l’unica parte della gestione delle credenziali che nessuna interfaccia invita mai qualcuno a fare. Scrivilo una volta e conservalo.
Due credenziali Tableau che fanno due lavori diversi. Una porta i permessi di una persona. L’altra estende una capacità della piattaforma. Scegliere quella giusta lascia al comando di chi vede cosa un modello di permessi che hai impiegato anni a costruire.
Una persona se ne va. Il suo nome resta su cartelle di lavoro, pianificazioni e sottoscrizioni, e diverse di queste si guastano senza un rumore. Cosa possiede, cosa si rompe, e l’ordine che mantiene la licenza recuperabile.
Un’affermazione è una frase. Una prova è qualcosa che una seconda persona può verificare senza chiedertelo. Cosa deve contenere una traccia di audit, cosa prova davvero un hash, e cosa pretendere da qualsiasi strumento che sostiene di produrne una.