drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Omernik (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DRILL-4129) Ability to Secure Storage plugins
Date Wed, 25 Nov 2015 15:24:11 GMT
John Omernik created DRILL-4129:

             Summary: Ability to Secure Storage plugins
                 Key: DRILL-4129
                 URL: https://issues.apache.org/jira/browse/DRILL-4129
             Project: Apache Drill
          Issue Type: Improvement
          Components: Storage - Other
    Affects Versions: 1.3.0
         Environment: All
            Reporter: John Omernik
             Fix For: Future

With more storage plugins hitting other data stores with their own authentication schemes,
(and thus having to embed credentials into the plugin for access) Drill thus needs the ability
to put security around these plugins.  Two approaches, perhaps both are needed, one is to
somehow challenge the user during the session for credentials and pass those credentials to
the underlying storage system. This would involve caching and may or may not be useable for
all cases .

The other is to provide a way to secure storage plugins, similar to how we secure views (i.e.
using filesystem permissions).  There was some discussion on the user list,  I copied one
of my posts here as a potential idea: 

Then I think the idea of securing each storage plugin may be a good idea.  Just an off the
cuff idea: What if we had an option to enable security for storage plugins (an opt in process)
that specified a filesystem location as a root location for storage plugins. 

Each storage plugin created would get a directory under that root.  


Then if I had a Mongo plugin named labmongo,  a jdbc plugin named labmysql, and a hbase plugin
named labhbase it would create directories that would be world readable as such:


These would be "world readable" as to be "visible"  If you didn't want them to be visible
to users, you could change the root permissions to be limiting, but only users who can read
them will have them shown in "show databases"

In those directories there would be an automatically created a directory called "security"
or "default"  

Permissions and ownership (for impersonation) for the plugin would be set by setting the filesystem
permissions on that directory (default/security)

Then you could create views for the storage plugin itself that would be located in the root:

And use permissions on those views like we do with permissions on filesystem locations. 

In addition, this model would allow us to create workspaces that are specific to certain tables
within the storage plugin (because now we'd have a place to store those workspaces) and those
works spaces could have permissions too.  

I can see potential pitfalls here, however, this gives flexibility and it matches the security
model for the filesystem plugin in that people wouldn't have "one" way to do security for
filesystem plugins, and another for non-filesystem plugins. It could help increase adoption
and ease people into using it through familiarity. 

This message was sent by Atlassian JIRA

View raw message