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 >
