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.
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
(v6.3.4#6332)
