[jira] [Commented] (DRILL-4129) Ability to Secure Storage plugins

["Dobes Vandermeer (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DRILL-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045186#comment-17045186 ] 

Dobes Vandermeer commented on DRILL-4129:
-----------------------------------------

I think an OK approach would be have each plugin add an option specifying a URL or somesuch where the password or other secret part of their configuration would come from.  If that is a file, them filesystem security would apply.

The target of the URL could be a keystore, or perhaps just a text file.  Maybe detect the file format based on file extension?

 

 

> 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
>            Priority: Major
>              Labels: security
>             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.  
> STORAGE_PLUGIN_SECURITY_ROOT="maprfs://data/storage_plugins"
> 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:
> /data/storage_plugins/labmongo
> /data/storage_plugins/labmysql
> /data/storage_plugins/labhbase
> 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:
> /data/storage_plugins/labmobgo/view_limited.json
> /data/storage_plugins/labmongo/view_other_limited.json
> 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
(v8.3.4#803005)