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 > > > > > >
