[jira] [Commented] (PHOENIX-4533) Phoenix Query Server should not use SPNEGO principal to proxy user requests

["Josh Elser (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16338308#comment-16338308 ] 

Josh Elser commented on PHOENIX-4533:
-------------------------------------

Using separate Kerberos identities for accepting requests and talking to HBase sounds like a great idea (especially, given the limitations of SPNEGO with Kerberos and Hadoop's impersonation rules).

My biggest concern is ensuring that ticket renewal happens for both principals, and that the HTTP principal is not used to talk to HBase at all. I'm thinking a setup like the following:

* Set short ticket lifetimes for the HTTP and hbase client kerberos principals (e.g. 10m)
* The HTTP user is not authorized to interact with any HBase tables, nor impersonate any end users
* Set up a PQS client to read from a Phoenix table through PQS at a regular interval (e.g. every 15s). Something trivial like a {{select *}} would be fine.

Then, just let this run for a few hours. At the end of the test, PQS should still be operational and the client can still read the Phoenix table through PQS.

It's a little elaborate to try to encapsulate this in an IT, but if you could run a standalone test, Lev, that'd be awesome.

> Phoenix Query Server should not use SPNEGO principal to proxy user requests
> ---------------------------------------------------------------------------
>
>                 Key: PHOENIX-4533
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4533
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Lev Bronshtein
>            Assignee: Lev Bronshtein
>            Priority: Minor
>         Attachments: PHOENIX-4533.1.patch
>
>
> Currently the HTTP/ principal is used by various components in the HADOOP ecosystem to perform SPNEGO authentication.  Since there can only be one HTTP/ per host, even outside of the Hadoop ecosystem, the keytab containing key material for local HTTP/ principal is shared among a few applications.  With so many applications having access to the HTTP/ credentials, this increases the chances of an attack on the proxy user capabilities of Hadoop.  This JIRA proposes that two different key tabs can be used to
> 1. Authenticate kerberized web requests
> 2. Communicate with the phoenix back end



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)