Estrategia de renovación de conexión de HBase Kerberos

Question

Recientemente habilité kerberos en mi clúster, todo funciona muy bien hasta que mi inicio de sesión kerberos caduca, por ejemplo, 12 horas. En ese momento, cualquier conexión que haya creado, cualquier tabla creada con esas conexiones, etc., se lanzará cuando las use. Esto podría bloquear mi aplicación dependiendo de cómo lo maneje.

No me importa colapsar enormemente porque mi aplicación está administrada por un control deslizante que resucitará la aplicación cuando se caiga, sin embargo, esto solo sucederá cuando HBase se "use" (es decir, llamo a un método en una mesa que ahora está obsoleto conexión), que probablemente sea causada por una interacción del usuario y esto conduciría a una mala experiencia de usuario

No quiero que los detalles de implementación de autenticación impregnen mi aplicación y tampoco quiero crear objetos de conexión más de lo necesario porque es una operación costosa que realiza una gran cantidad de llamadas RPC (ubicación de metadatos de zookeeper para empezar).

¿Existe una estrategia común (preferiblemente incorporada en el cliente HBase) para administrar la caducidad de autenticación Kerberos y renovar las conexiones / tablas HBase cuando eso sucede?

Answer 1

Un TGT de Kerberos tiene una vida útil (por ejemplo, 12 h) y una vida renovable (por ejemplo, 7 días). Siempre y cuando el boleto siga siendo válido y sea renovable, puede solicitar una renovación "gratuita", no se requiere contraseña, y el contador de por vida se reinicia (por ejemplo, 12 horas para volver, nuevamente).

La biblioteca de autenticación Hadoop genera un hilo Java específico para la renovación automática del TGT actual. Es un poco feo, usando una línea de comando kinit -R lugar de una llamada a la biblioteca JAAS, pero funciona - vea HADOOP-6656

Por lo tanto, si consigue que Slider cree un ticket renovable en el inicio, y si puede sobornar a su SysAdmin para aumentar el tiempo de vida renovable predeterminado (cf. client conf) y max (cf. KDC conf) a, digamos, 30 días, entonces su aplicación podría funcionar durante 30 días seguidos con el TGT inicial. Una buena mejora

~~~~~~~~~~

Si realmente anhelas la eternidad ... lo siento, pero en realidad tendrás que programar. Eso significa un hilo / proceso dedicado a cargo o recrear automáticamente el TGT.

• La forma Java: al inicio, antes de conectarse a HBase / HDFS / lo que sea, cree explícitamente una UGI con loginUserFromKeytab() luego ejecute checkTGTAndReloginFromKeytab() de vez en cuando
• El modo Shell: inicie un shell que (a) cree un TGT con kinit (b) genere un subproceso que periódicamente active kinit nuevamente (c) inicie su aplicación Java y luego elimine el subproceso cuando su aplicación alguna vez finalice

Advertencia: si algún otro hilo abre o vuelve a abrir una conexión mientras se vuelve a crear el TGT, esa conexión puede fallar porque el caché estaba vacío en el momento exacto en que se accedió ("condición de carrera"). El próximo intento será exitoso, pero espere algunas advertencias falsas en sus registros.

~~~~~~~~~~

Consejo final: puede usar un caché de tickets privado para su aplicación (es decir, puede ejecutar múltiples aplicaciones en el mismo nodo con la misma cuenta de Linux pero diferentes principales de Kerberos) configurando la variable de entorno KRB5CCNAME , siempre que sea un caché "FILE:" .