Strategia di rinnovo della connessione Kerberos HBase

Question

Recentemente ho abilitato kerberos nel mio cluster, tutto funziona alla grande fino a quando il mio login kerberos scade, per esempio, 12 ore. A quel punto tutte le connessioni che ho creato, tutte le tabelle create con quelle connessioni ecc. Verranno lanciate quando le uso. Questo potrebbe potenzialmente mandare in crash la mia app a seconda di come la gestisco.

Non mi preoccupo di crashing enormemente perché la mia app è gestita da slider che farà risorgere l'app se e quando va giù, tuttavia questo accadrà solo quando HBase è "usato" (cioè chiamo un metodo su un tavolo con una connessione ormai obsoleta) che sarà probabilmente causata da un'interazione dell'utente e questo porterebbe a UX scadente.

Non voglio che i dettagli di implementazione dell'autenticazione pervadano la mia applicazione e inoltre non voglio creare oggetti di connessione più spesso del necessario perché è un'operazione costosa che fa un gran numero di chiamate RPC (posizione dei metadati del guardiano zoografico verso iniziare con).

Esiste una strategia comune (preferibilmente integrata nel client HBase) per la gestione della scadenza dell'autenticazione Kerberos e il rinnovo delle connessioni/tabelle HBase quando ciò accade?

Answer 1

Kerberos TGT ha una durata (ad esempio 12 ore) e una durata rinnovabile (esempio 7 giorni). Finché il ticket è ancora valido ed è ancora rinnovabile, è possibile richiedere un rinnovo "gratuito", senza richiedere la password, e il contatore della durata viene ripristinato (ad esempio 12 ore per andare, di nuovo).

La libreria di autenticazione Hadoop genera un thread Java specifico per il rinnovo automatico del TGT corrente. È un po 'brutto, utilizzando una linea kinit -R di comando invece di una chiamata di libreria JAAS, ma funziona - vedi HADOOP-6656

Quindi, se si ottiene Slider per creare un biglietto da fonti rinnovabili all'avvio, e se è possibile corrompere la vostra SysAdmin per aumentare l'impostazione predefinita (cfr. conf. client) e la massima (conf. KDC) durata illimitata a, ad esempio, 30 giorni, quindi l'app potrebbe essere eseguita per 30 giorni direttamente con il TGT iniziale. Un bel miglioramento.

~~~~~~~~~~

Se davvero ha bisogno per l'eternità ... scusa, ma sarà effettivamente avere un po 'di programmazione da fare. Ciò significa che un thread/processo dedicato è in carica o che ricrea automaticamente il TGT.

• The Way Java: all'avvio, prima di connettersi a HBase/HDFS/qualunque cosa, creare esplicitamente un UGI con loginUserFromKeytab() quindi eseguire checkTGTAndReloginFromKeytab() di tanto in tanto
• La Via Shell: avviare una shell che (a) crea un TGT con kinit (b) genera un sottoprocesso che spara periodicamente kinit nuovo (c) lancia la vostra applicazione Java poi uccide il sottoprocesso quando/se la vostra applicazione mai termina

Avvertenza: se qualche altro thread si apre per aprire o riaprire una connessione mentre il TGT viene ricreato, quella connessione potrebbe fallire perché la cache era vuota al momento esatto in cui era stata acceduta ("race condition") . Il prossimo tentativo avrà esito positivo, ma si attendono alcuni avvisi non validi nei log.

~~~~~~~~~~

consiglio finale: si può usare una cache biglietteria per la tua app (ad esempio è possibile eseguire più applicazioni sullo stesso nodo con lo stesso account Linux, ma diversi principi Kerberos) impostando la variabile di ambiente KRB5CCNAME, purché si tratti di una cache "FILE:".