Sorry I noticed that documentation/link after I sent the original message.  I 
also found the documentation on “Configuring User Impersonation” and 
“Configuring Inbound Impersonation” to be useful and relevant.

I am not sure that these will be adequate though.  Drill supports inbound 
impersonation, but I think I need the opposite, outbound impersonation.  

For example, I can setup Drill to use LDAP, and “Joe” can login to the machine. 
 He may do a query joining the database with another source.  Drill can use 
impersonation to execute these queries as Joe.  Unfortunately though, Joe’s 
credentials for the backend database may not be the same as his LDAP 
credentials, and they may be different for the other data sources.  Joe could 
configure the storage plugins to use his database username/password, but 
wouldn’t that also make his password visible to all users?

I guess I can summarize this with one question: Can Drill support separate 
storage plugin configurations per user?

On 5/2/17, 2:36 PM, "Kunal Khatua" <[email protected]> wrote:

    Have you had a look at this link?
    
    https://drill.apache.org/docs/configuring-user-authentication
    
    Configuring User Authentication - Apache 
Drill<https://drill.apache.org/docs/configuring-user-authentication/>
    drill.apache.org
    Authentication is the process of establishing confidence of authenticity. A 
Drill client user is authenticated when a drillbit process running in a Drill 
cluster ...
    
    
    - Kunal
    
    ________________________________
    From: Knapp, Michael <[email protected]>
    Sent: Tuesday, May 2, 2017 8:33:03 AM
    To: [email protected]
    Cc: Chagani, Hassan; Swift, John
    Subject: multiple users and passwords
    
    Drill Developers and Supporters,
    
    I am hoping to use drill to query a SQL databaes.  There will be many 
different users accessing the drill web console, and each of them have separate 
credentials for accessing the database.  I have the requirement of supporting 
drill queries to the database using the credentials provided by the current 
user.  I am struggling to find a way to do this in drill because I noticed that:
    
    ·         The documentation instructs me to provide the username and 
password in the storage plugin, either in the ‘url’ field or as separate 
‘username’ and ‘password’ fields.
    
    ·         As far as I know, Drill does not support user logins or various 
permission models.
    
    So as I see it, if a person can reach the drill web console, then they can 
also see all of the storage plugin configurations.  That means they can see the 
passwords in clear text.  If I opened this up to multiple users, then each of 
them could see everybody else’s passwords.  I cannot simply create a system 
account to perform queries on behalf of others because we have auditing 
requirements.
    
    I also noticed that completed queries are logged in the “Profiles” tab on 
the console.  So if somehow I configure things such that credentials are passed 
in a query, they would still be visible to other users by viewing completed 
queries.  So I would also need to prevent that somehow.
    
    Does anybody know how I can provide drill with each user’s credentials 
without sharing them with every user?
    
    I don’t see any way to provide credentials in a select statement to my 
database, it looks like it can only be provided while forming a connection.
    
    I was thinking, maybe I can write a new storage plugin that wraps the RDBMS 
plugin, and consumes credentials by some other method.  I don’t see any 
documentation on how to write your own storage plugin.
    
    Any ideas or suggestions would be greatly appreciated.
    
    Michael Knapp
    ________________________________________________________
    
    The information contained in this e-mail is confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.
    

________________________________________________________

The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.

Reply via email to