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