Oozie Java Action accès à Hive Server 2 (Kerberized) en utilisant le jeton de délégation

Question

Actuellement, j'ai un problème vraiment besoin d'aide. Nous essayons kerberize notre cluster hadoop y compris rive server2 et oozie. Mon job oozie crée une action java dans un noeud de données qui tente de se connecter au serveur ruche kerberisé 2. Il n'y a pas de keytab kerberos pour l'authentification. Je ne peux donc utiliser que le jeton de délégation passé par oozie dans l'action java pour me connecter au serveur hive 2. Ma question est la suivante: est-il possible d'utiliser le jeton de délégation dans une action oozie java pour se connecter au serveur hive 2? Si oui, comment puis-je le faire via Hive JDBC? Merci Jary

Answer 1

Lorsque vous utilisez oozie dans un cluster kerberisé ...

• pour une action "Ruche" ou "porc", vous devez configurer <credentials> de Type HCAT
• pour une "Hive2" Action (vient de sortir avec V4.2) vous devez configurer <credentials> de type Hive2
• pour une action "Java" ouvrant une connexion JDBC personnalisée à HiveServer2, Je crains qu'Oozie ne puisse pas aider - à moins qu'il y ait un hack non documenté qui permettrait de réutiliser ce nouveau credible Hive2?!?

Référence: oozie documentation about Kerberos credentials

vous ne pouvez pas autant que je sache utiliser des jetons de délégation Hadoop avec HiveServer2. HS2 utilise Thrift pour gérer les connexions client, et Thrift supporte Kerberos; mais les jetons de délégation Hadoop sont quelque chose de différent (Kerberos n'a jamais été destiné à l'informatique distribuée, une solution de contournement est nécessaire)

Qu'est-ce que vous pouvez faire est navire un ensemble complet de configuration GSSAPI, y compris un keytab, dans votre " Java "Action.Il fonctionne, mais il y a un certain nombre de mises en garde:

1. la bibliothèque Hadoop Auth semble être câblé sur le cache billet locale d'une manière très boiteux; Si vous devez vous connecter à HDFS et à HiveServer2, alors faites d'abord HDFS, car dès que JDBC lance son propre ticket basé sur votre conf personnalisé, l'authentification Hadoop sera rompue
2. La configuration de Kerberos est délicate, la configuration de GSSAPI est pire et depuis ce sont des fonctions de sécurité les messages d'erreur ne sont pas très utiles , par la conception (serait mauvais goût de dire pourquoi les pirates leur intrusion tentative a été rejetée)
3. utilisation OpenJDK si possible; par défaut, la machine virtuelle Java de Sun/Oracle a limites sur la cryptographie (à cause de stupides et politiques obsolètes exportations des États-Unis ) donc vous devez télécharger 2 fichiers JAR avec les paramètres crypto « illimité résistance » pour remplacer ceux par défaut

Référence: un autre StackOverflow post que j'ai trouvé très utile pour configurer l'authentification Kerberos "brute" lors de la connexion à HiveServer2; plus un lien sur un very helpful "trace flag" pour déboguer votre config GSSAPI par exemple.

-Djava.security.debug=gssloginconfig,configfile,configparser,logincontext 

Avertissement final: Kerberos est la magie noire. Ça va aspirer ton âme. Plus prosaïquement, il vous fera perdre beaucoup de jours-homme à des problèmes de configuration énigmatique, et le moral de l'équipe en souffrira. Nous avons été là.