We should plan to support hive jdbc connectivity to a kerberized hive server2. This requires to provide an option where each user will create a connection using a proxy user/pwd which will be passed to backend hive server2 as part of “hive.server2.proxy.user=” as part of jdbc url like below.

jdbc:hive2:/myhostname:10000/;principal=hive/_HOST@EXAMPLE.COM;hive.server2.proxy.user=

Implementing the query runner to pass user information to the data source is possible. But the hard part is that it goes against all assumptions in Redash, that assumes that the user who has access to a query can also run it. It’s will be more inline with how Redash works to setup group users, and assign them to the relevant data sources/groups in Redash.

This way you can still control access among users, but also be consistent with how Redash works.

Hi, Having data source driven approach can not tell which user has actually fired what query when the query reaches the hive backend. For all queries it can only tell that it has come from data source1 user or data source2 user. To know exactly query log we need to rely on Redash logging to correlate the log in Redash and the backend query which is actually executed at Hive, which IMO may become tricky to correlate unless there is UUID or some identifier which comes as part of the query to backend.