Got it Yes, you can certainly have multiple Mongo datastores set up in Drill. Or multiple JDBC datastores, ...
On Mon, Oct 26, 2015 at 1:12 PM, John Omernik <[email protected]> wrote: > I was just saying that if we are only allowed "one" mongo storage plugin, > (or one of any given type, hbase, jdbc) then we'd need to do something that > passes the identify through from the user, in a manual process of some > sort. But if I can have multiple mongo plugins, and different permissions > on them I have more flexibility. > > The scenario I am thinking about is in enterprises that have some old > database server, that perhaps you can connect to it with jdbc to pull data > out, but no one on the dev team wants to implement any changes to the > system. (I.e. no granular security) They implement security through a > strict IP based (firewalls etc) security model: Very weak to be sure. > However, if something could be setup where the drill bits were given access > to the IP, it could then have security built on top of that using views (if > we had permissions on the storage plugin). This is not the "right" way to > do data, and I am not advocating it, it would just be a nice tool to use > for those orgs that where there is a possibility of access data, and using > it in a better way, but then using drill to help clean things up from a > security perspective. > > > > On Mon, Oct 26, 2015 at 2:34 PM, Tomer Shiran <[email protected]> wrote: > > > If the devs didn't lock down the Mongo cluster, then I'm not sure that > > limiting the number of storage plugins in the Drill cluster can help. At > > the end of the day, the rouge user could access the Mongo cluster > > irrespective of Drill, using the Mongo API, or they could even set up > their > > own Drill cluster and access it from there. > > > > Or maybe I misunderstood the point you were making... > > > > On Mon, Oct 26, 2015 at 12:01 PM, John Omernik <[email protected]> wrote: > > > > > 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 <[email protected]> > > > 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 <[email protected]> > > > > 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 > > > > > [email protected] > > > > > 443-718-0098 > > > > > MapR Technologies > > > > > http://www.mapr.com > > > > > On Oct 26, 2015 1:54 PM, "John Omernik" <[email protected]> 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 < > > > > > > [email protected]> 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 < > [email protected]> > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Tomer Shiran > > CEO and Co-Founder, Dremio > > > -- Tomer Shiran CEO and Co-Founder, Dremio
