Mailing-List: contact dev-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Wed, 25 Nov 2015 15:24:11 +0000 (UTC)
From: "John Omernik (JIRA)" <jira@apache.org>
To: dev@drill.apache.org
Message-ID: <JIRA.12916178.1448465046000.192085.1448465051028@Atlassian.JIRA>
In-Reply-To: <JIRA.12916178.1448465046000@Atlassian.JIRA>
References: <JIRA.12916178.1448465046000@Atlassian.JIRA>
 <JIRA.12916178.1448465046633@arcas>
Subject: [jira] [Created] (DRILL-4129) Ability to Secure Storage plugins
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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)