Vous ne savez pas ce qui se passe puisqu'il y a plusieurs pièces mobiles ici. Nous avons un cluster cloudera pour hdfs, hadoop, impala, hbase. Nous avons également un loadbalancer F5 devant tous nos serveurs d'impala. Nous essayons de sécuriser les serveurs/cluster avec Kerberos. Mon collègue a installé Kerberos en utilisant MIT KDC. Cette configuration fonctionne correctement lorsque nous interrogeons impala directement sur le serveur, mais pas lorsque nous passons par un équilibreur de charge F5.Changement du nom du principal du service dans Kerberos
Nous avons exécuté kinit pour obtenir un ticket pour un fichier keytab pré-créé.
kinit -k -t /blah/keytabs/first.last.keytab first.last
Quand je lance klist, il montre tous ces billets:
$ klist
Ticket cache: FILE:/tmp/krb5cc_14377
Default principal: [email protected]
Valid starting Expires Service principal
08/23/17 11:32:02 08/24/17 11:32:02 krbtgt/[email protected]
renew until 08/23/17 11:32:02
08/23/17 11:33:39 08/24/17 11:32:02 impala/[email protected]
renew until 08/23/17 11:32:02
Quand je lance ma commande impala-shell, il fonctionne très bien:
$ impala-shell -i hslave32101.company.com:21000 -k -q "select 1"
Starting Impala Shell using Kerberos authentication
Using service name 'impala'
Connected to hslave32101.company.com:21000
Server version: impalad version 2.7.0-cdh5.9.2 RELEASE (build 2f7871169d894fab16f8a2fb99f2e34f0df8763d)
Query: select 1
Query submitted at: 2017-08-23 13:08:34 (Coordinator: http://hslave32101.company.com:25000)
Query progress can be monitored at: http://hslave32101.company.com:25000/query_plan?query_id=4940ca8ca2f267c5:5eeb29af00000000
+---+
| 1 |
+---+
| 1 |
+---+
Fetched 1 row(s) in 0.01s
Cependant, quand je lance ma commande via le loadbalancer F5, ça ne marche pas car le ticket recherché ne correspond pas à klist car il a remplacé une partie de celui-ci pour une raison quelconque.
impala-shell -i bdaudit.company.com:21000 -d bigdata -k -q "select 1"
Starting Impala Shell using Kerberos authentication
Using service name 'impala'
Error connecting: TTransportException, Could not start SASL: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/[email protected] not found in Kerberos database)
Not connected to Impala, could not execute queries.
Le problème est cette ligne ici
(Server krbtgt/[email protected] not found in Kerberos database)
D'une certaine manière lors du passage à travers le F5 VIP, il change [email protected] à [email protected]~~V~~singular~~3rd. Est-ce que quelqu'un sait pourquoi il a remplacé cette partie du billet?
1/2 « Mon collègue a installé Kerberos utilisant MIT KDC Cette configuration fonctionne très bien lorsque nous interrogeons directement l'impala sur le serveur, mais pas lorsque nous passons par un équilibreur de charge F5. -> Alors, juste une petite question à ce sujet. Le F5 est-il configuré pour le transfert vers votre serveur d'applications ou est-il configuré en tant que proxy inverse? Je pense qu'il doit être configuré en tant qu'équilibreur de charge pass-through pour que Kerberos fonctionne, sinon le trafic d'authentification sera stoppé et abandonné sur le F5 sans autre configuration au F5. Je prends une supposition éclairée ici. –
2/2 "Cependant, lorsque je lance ma commande via le loadbalancer F5, cela ne fonctionne pas car le ticket recherché ne correspond pas à ce qu'il y a dans klist car il en a remplacé une partie pour une raison quelconque ... à travers le VIP F5, il change [email protected] à [email protected] Est-ce que quelqu'un sait pourquoi il a remplacé cette partie du ticket? " -> Ces déclarations semblent confirmer que votre F5 agit comme un proxy inverse vers l'impala. Pouvez-vous confirmer ou infirmer cela? Je ne pense pas que cela fonctionnera sans configuration supplémentaire à la F5. –
@ T-Heron, Merci pour votre intérêt pour ma question. Le F5 est configuré comme un passage à travers. Nous l'avons eu après avoir trouvé la documentation de Cloudera sur la façon de le faire. Nous ne savons toujours pas pourquoi le nom a changé dans l'erreur, à part un pressentiment que le KDC essayait de trouver une ressource appelée bdaudit.company.com, ne pouvait pas puisque les ressources sont hslave33333.company.com et pour une raison quelconque, tronqué le nom à être [email protected] – Classified