[
https://issues.apache.org/jira/browse/DRILL-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045191#comment-17045191
]
Dobes Vandermeer commented on DRILL-4129:
-----------------------------------------
Should plugins follow the model set by S3 ?
https://issues.apache.org/jira/browse/DRILL-6662
> 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)
