Keys - Thanks for the information, however, to Steve's question, there is no way to secure the storage plugin itself, and thus any credentials to systems downstream that require credentials (MongoDB, S3, JDBC, etc) can not be secured. There is only one user that has access to those downstream systems, and thus the impersonated user has no affect on the security of the data downstream. Even with views, there is nothing in drill that can prevent a user from using the storage plugin directly, and thus you have a shared user, defeating accountability and limiting the ability to protect the confidentiality of data.
John On Fri, Jul 29, 2016 at 9:08 AM, Keys Botzum <kbot...@maprtech.com> wrote: > Drill does use HDFS/Mapr-FS impersonation to push identity down to the > underlying storage system - HDFS, MapR-FS, MapR-DB. Once that is done the > underlying storage system can then perform authorization. This is a robust > model that is advantageous as it ensures that data is protected the same > way regardless of access path. It may be that there are additional storage > systems which Drill does not yet impersonate to. Can you say more in terms > of requirements? > > Drill impersonation: > https://drill.apache.org/docs/configuring-user-impersonation/ > > In addition Drill supports views which can be created and shared amongst > users. Basically I can create a view on data I own and share that view with > others that can't see the underlying data but can see the view. > > Drill views: http://drill.apache.org/docs/create-view-command/ > > Keys > _______________________________ > Keys Botzum > Senior Principal Technologist > kbot...@maprtech.com <mailto:kbot...@maprtech.com> > 443-718-0098 > MapR Technologies > http://www.mapr.com <http://www.mapr.com/> > > On Jul 29, 2016, at 9: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. > >
