Yes, I would say that approach (permissions to the plugins themselves) is a more ubiquitous solution, and allows Drill to be the place to set permissions as exposed to the users. I.e. sometimes there are just poor setups with poor security (a mongo DB setup where the devs didn't lock it down) by using a storage plugin permission setup, we can "add" security via drill even when the source data doesn't have any.
One quick question as it pertains to this discussion, there aren't any limitations on how many Mongo plugins, or how many jdbc plugins we can have are there? That would be show stopper for applying security from this perspective. John On Mon, Oct 26, 2015 at 1:34 PM, Jacques Nadeau <jacq...@dremio.com> wrote: > Agreed. > > We can also provide a general solution: storage plugin access permissions. > If someone can't access the storage plugin, then we could use Drill views > to manage security. The problem right now is that everyone has access to > every storage plugin (and in the case of JDBC, Mongo and HBase, that means > it is an open window into the underlying system). > > -- > Jacques Nadeau > CTO and Co-Founder, Dremio > > On Mon, Oct 26, 2015 at 11:00 AM, Keys Botzum <kbot...@maprtech.com> > wrote: > > > Identity assertion from drill via jdbc to the underlying database is > > needed. It's been years since I looked at this but most databases have a > > way of doing this. The technique was unique to each database in the past. > > > > Keys > > _______________________________ > > Keys Botzum > > Senior Principal Technologist > > kbot...@maprtech.com > > 443-718-0098 > > MapR Technologies > > http://www.mapr.com > > On Oct 26, 2015 1:54 PM, "John Omernik" <j...@omernik.com> wrote: > > > > > So if I create a JDBC Storage Plugin with JSON below. I now have a > > storage > > > plugin available to all users in drill. There is no limiting who can > use > > > that (that I can tell). So then in this case, I have a user (myuser) > who > > > is authenticating to the Mysql server. That means, ALL users of drill > > will > > > have the access rights of myuser on the MySQL Server. This is not an > > ideal > > > situation. > > > > > > Ideally, we could have a "service" user of some sort connected between > > > Drill and the MySQL Server, this would be the equivalent of the super > > user > > > on drill. Then from there, we could create views with permissions > (just > > > like filesystem based views) where we could select who could select > from > > > view, allowing us to wrap some security around the situation. In a > > perfect > > > world, we'd have a way to pass the credentials to the JDBC driver from > > the > > > query, but that seems fraught with issues (usernames/passwords in the > > query > > > logs to start with). We could create multiple storage plugins for > > > different levels of access to the various JDBC tables, but we'd still > > have > > > no way of controlling who could use the various plugins. (Unless I am > > > missing something obvious here). Basically, as I see it now, there > is > > no > > > way to limit who can use a storage plugin in drill. > > > > > > > > > Storage Plugins Creation: > > > > > > { > > > > > > "type": "jdbc", > > > > > > "driver": "com.mysql.jdbc.Driver", > > > > > > "url": "jdbc:mysql://localhost:3306/mydb", > > > > > > "username": "myuser", > > > > > > "password": "mypass", > > > > > > "enabled": false > > > > > > } > > > > > > > > > On Mon, Oct 26, 2015 at 12:00 PM, Neeraja Rentachintala < > > > nrentachint...@maprtech.com> wrote: > > > > > > > Hi John > > > > > > > > Can you please elaborate on what you mean by authentication to the > > source > > > > system is going to be wide open in Drill. > > > > > > > > Drill is a query layer on data sources and will respect the > underlying > > > > storage permissions without having to manage centralized security > > > > permissions at Drill layer through user impersonation. Users can use > > > Drill > > > > views if they need more granular access to the data. > > > > > > > > I would be interested in learning more about your use case to secure > > the > > > > storage plugin/connections. > > > > > > > > thanks > > > > > > > > On Mon, Oct 26, 2015 at 6:33 AM, John Omernik <j...@omernik.com> > > wrote: > > > > > > > > > Hey all - > > > > > > > > > > On file system based storage plugins, security is straight forward > > with > > > > > filesystem permissions etc. How do we secure storage plugins? It > > > would > > > > > seem we would want a situation where people could not access > certain > > > > > storage plugins especially since authentication to the source > system > > is > > > > > going to be "wide open" (i.e. there is no pass through auth to a > > > backend > > > > > Mongo server, JDBC system, or Hbase setup) thus how do we wrap > > > security > > > > > around these? > > > > > > > > > > Even basic security... i.e. only X user can use them, so we can use > > > them > > > > to > > > > > load parquet tables or something where we can apply security. > > > > > > > > > > Thoughts? > > > > > > > > > > John > > > > > > > > > > > > > > >
