Good question Steve. I know I've posted some items related to securing of storage plugins. Perhaps not using Drill itself to secure this, but instead using a file directory and thus using filesystem permissions to store the definitions and secure them. (The alternative is to add a znode with unix like permissions there). Basically using the same approach to secure storage plugins as we use for drill views. This would be very beneficial, both for S3 stuff, but also for JDBC plugin stuff. There has also been some conversation around passing credentials to the JDBC plugin to auth per user, but no work done specifically (that I am aware of)
These are important enterprise level features that I think are very important to the adoption of Drill. On Fri, Jul 29, 2016 at 8:50 AM, Steve Warren <swar...@myvest.com> wrote: > With Drill I can authenticate a user and distinguish between ADMIN and > USER. However, there doesn't seem to be much (any) in the way of per user > authorizations beyond that. Example uses being: > > 1) Allowing for per user AWS credentials. > 2) Returning a token or other profile information from the authentication > process that can be passed into each storage plugin. > 3) ACL for storage plugins (by user group). > > Are there any plans to extend the authorization capabilities in these > areas? > > Cheers > > -- > Confidentiality Notice and Disclaimer: The information contained in this > e-mail and any attachments, is not transmitted by secure means and may also > be legally privileged and confidential. If you are not an intended > recipient, you are hereby notified that any dissemination, distribution, or > copying of this e-mail is strictly prohibited. If you have received this > e-mail in error, please notify the sender and permanently delete the e-mail > and any attachments immediately. You should not retain, copy or use this > e-mail or any attachment for any purpose, nor disclose all or any part of > the contents to any other person. MyVest Corporation, MyVest Advisors and > their affiliates accept no responsibility for any unauthorized access > and/or alteration or dissemination of this communication nor for any > consequence based on or arising out of the use of information that may have > been illegitimately accessed or altered. >
