[
https://issues.apache.org/jira/browse/CALCITE-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1318:
------------------------------------
Fix Version/s: (was: avatica-1.12.0)
avatica-1.13.0
> Build/Document Avatica Kerberos/SPNEGO authentication behind load balancer.
> ---------------------------------------------------------------------------
>
> Key: CALCITE-1318
> URL: https://issues.apache.org/jira/browse/CALCITE-1318
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Major
> Fix For: avatica-1.13.0
>
>
> I was talking with [~_alexm] this weekend about some work that he had
> recently done in getting Apache Impala set up behind a load balancer. When
> Kerberos is in the picture, he told me that the way that works is that the
> impalad daemons actually have two Kerberos identities: one for the hostname
> that the impalad service is actually running on and another for the load
> balancer host. The load-balancer continues to just do a simple pass-through.
> Right now, the Avatica server can only accept a single Kerberos
> principal+keytab. This means that we can't use the Kerberos authentication
> when the client can access the server via multiple hostnames -- invalidating
> the use of 'dumb' load balancers (hypothetically, a smart loadbalancer could
> make it work). We could configure the Avatica server to use a principal with
> the load-balancer's hostname, but then users would be unable to connect
> directly to the server.
> I know that Impala uses (or at least exposes) Thrift which has its own SASL
> implementation; maybe they do something tricky there? Maybe we can glean
> something from their implementation (even though it's not HTTP based). I
> don't think JAAS lets us have multiple active logins, so I'm not even sure
> where to begin.
> Ideally, this is something that would be great to understand and provide some
> deployment guidance for users to have identical deployment scenario for
> "secure" and "unsecure" scenarios.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
