[ 
https://issues.apache.org/jira/browse/HBASE-30432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated HBASE-30432:
-----------------------------------
    Labels: pull-request-available  (was: )

> [Thrift] Add hostname override support for ThriftServer
> -------------------------------------------------------
>
>                 Key: HBASE-30432
>                 URL: https://issues.apache.org/jira/browse/HBASE-30432
>             Project: HBase
>          Issue Type: Improvement
>          Components: security, Thrift
>    Affects Versions: 2.4.15
>            Reporter: Jack Yang
>            Assignee: Jack Yang
>            Priority: Minor
>              Labels: pull-request-available
>
> When HBase ThriftServer runs with Kerberos/SASL enabled, it determines its 
> hostname using:
> {code:java}
> DNS.getDefaultHost( 
>     conf.get(THRIFT_DNS_INTERFACE_KEY, "default"), 
>     conf.get(THRIFT_DNS_NAMESERVER_KEY, "default")){code}
> The resulting hostname is then used for Kerberos login and as the SASL server 
> hostname.
> This works well when clients connect directly to the physical hostname of 
> each ThriftServer, but causes problems when multiple ThriftServer instances 
> are exposed through a common service hostname, for example using DNS 
> round-robin, a VIP, or an L4 load balancer.
> Example deployment:
> {code:java}
> hbase-thrift.example.com 
> A -> 10.0.0.11 (host1) 
> A -> 10.0.0.12 (host2) 
> A -> 10.0.0.13 (host3){code}
> Clients connect to:
> {code:java}
> hbase-thrift.example.com:9090{code}
> and therefore use the Kerberos service principal:
> {code:java}
> hbase/[email protected]{code}
> However, each ThriftServer currently discovers its physical hostname using 
> {{{}DNS.getDefaultHost(){}}}, for example:
> {code:java}
> host1 
> host2 
> host3{code}
> and initializes its SASL server using those hostnames.
> This results in a mismatch between the service hostname used by the client 
> and the hostname used by the ThriftServer SASL endpoint. In this case, GSSAPI 
> authentication can fail because the client requests a ticket for the virtual 
> service hostname while the ThriftServer initializes its SASL endpoint using 
> the physical host name.
> The existing configurations:
> {code:java}
> hbase.thrift.dns.interface 
> hbase.thrift.dns.nameserver
> {code}
> allow selecting the interface and DNS server used for hostname discovery, but 
> do not provide a way to explicitly override the hostname used by ThriftServer.
> Changing the operating system hostname, {{{}/etc/hosts{}}}, or reverse DNS is 
> not always desirable because the same hosts may run other Hadoop services 
> such as HDFS, whose Kerberos principals depend on their physical hostnames.
> *Proposed Change*
> Add a ThriftServer-specific hostname override configuration:
> {code:java}
> hbase.unsafe.thrift.hostname{code}
> When this configuration is set, ThriftServer should use the configured 
> hostname instead of calling {{{}DNS.getDefaultHost(){}}}.
> Conceptually:
> {code:java}
> String configuredHost = conf.getTrimmed(THRIFT_HOSTNAME_KEY); 
> if (configuredHost != null && !configuredHost.isEmpty()) { 
>     host = configuredHost; 
> } else { 
>     host = Strings.domainNamePointerToHostName( 
>       DNS.getDefaultHost( 
>         conf.get(THRIFT_DNS_INTERFACE_KEY, "default"), 
>         conf.get(THRIFT_DNS_NAMESERVER_KEY, "default"))); 
> }{code}
> Example configuration:
> {code:java}
> <property> 
>   <name>hbase.unsafe.thrift.hostname</name> 
>   <value>hbase-thrift.example.com</value> 
> </property> 
> <property> 
>   <name>hbase.thrift.kerberos.principal</name> 
>   <value>hbase/[email protected]</value> 
> </property>{code}
> The resulting ThriftServer service principal would be:
> {code:java}
> hbase/[email protected]{code}
> All ThriftServer instances behind the common service hostname can then use a 
> keytab containing this service principal.
> If {{hbase.unsafe.thrift.hostname}} is not configured, the existing hostname 
> discovery behavior remains unchanged.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to