[
https://issues.apache.org/jira/browse/IMPALA-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Ho updated IMPALA-5023:
-------------------------------
Labels: kerberos (was: )
> supportability: DNS GLSB in front of IMPALA (env: Kerberos+SSL)
> ---------------------------------------------------------------
>
> Key: IMPALA-5023
> URL: https://issues.apache.org/jira/browse/IMPALA-5023
> Project: IMPALA
> Issue Type: New Feature
> Components: Security
> Affects Versions: Impala 2.5.0
> Reporter: Adriano Simone
> Priority: Major
> Labels: kerberos
>
> Issue Description:
> In a hardened cluster (kerberos+ssl) a dns loadbalancer cannot be used in
> front of the impalad because the user's connection attempt will fail with a:
> GSS failiure (Wrong principal in request).
> The reason seem to be that the DNS GLSB every time resolve its own address
> with the ipaddress of a different impalad (as per the DNS LB roundrobin
> fashion) and when the impalad try to reverse the address it get a different
> hostname that doesn't match the one in the principal.
> Test performed to check the case:
> Sample Environment description:
> * CDH 5.7.4
> * KERBEROS + SSL
> * DNS GLSB in front of Hive/Impala
> Try to use beeline to connect to the impala JDBC service using the command:
> {code:java}
> beeline
> 'jdbc:hive2:///dns.gslb:21050/;ssl=true;principal=impala/[email protected]'
> {code}
> The impalad refuse the authentication with the error:
> {code:java}
> E1229 08:31:22.778329 22628 authentication.cc:155] SASL message (Kerberos
> (external)): GSSAPI Error: Unspecified GSS failure. Minor code may provide
> more information (Wrong principal in request)
> {code}
> The DNS GLSB every time resolve the address 'dns.gslb' with the ipaddress of
> a different impalad (as a DNS LB roundrobin).
> Most probably this happen because the impalad try to resolve and reverse the
> DNS GLSB hostname that point every time a different impalad (and this will
> prevent the principal matching during the authentication).
> Impala is correctly configured to accept it as below:
> {code:java}
> --be_principal=impala/[email protected]
> --principal=impala/[email protected]
> --keytab_file=/var/run/cloudera-scm-agent/process/10247-impala-IMPALAD/impala.keytab
> {code}
> and the impala.keytab contain the principal for the DNS glsb and the impalad
> it self.
> During our analysis this seems to happen because the impalad try to
> resolve/reverse the hostname of the DNS GLSB that every time point to a
> different impalad (as per the DNS LB roundrobin fashion).
> This is not happening with Hive that seems to works with this "dns gslb".
> The DNS GSLB is used by many Companies in Enterprise environment and it is
> well integrated with an high number of applications.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
