[jira] [Commented] (SENTRY-14) Multiple components and sentry-site.xml/providers

["Gregory Chanan (JIRA)" <ji...@apache.org>]

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

Gregory Chanan commented on SENTRY-14:
--------------------------------------

Here are some initial thoughts...

1) Provider resource
it seems difficult to maintain role mappings for multiple services in the same file, at least without changing the syntax.  Let's say I have some policy like:
{code}
users = server=server1->db=database->table=sometable->action=Select
{code}

Does this apply to both hive and impala?  What if I just want it to apply to one and not the other, how do I specify that?  With multiple services, can we even provide good error messages (if there is a syntax error, how do we know which service they were trying to use?)  It just seems cleaner to use a per-service provider resource.

2) sentry-site.xml

I'm more split on this one, because I don't think there are as many complications as in the provider resource case.  With a single sentry-site.xml I could specify multiple provider resources like so:
{code}
<property>
  <name>sentry.hive.provider.resource</name>
  <value>/path/to/hive/auth/file</value>
</property>
<property>
  <name>sentry.solr.provider.resource</name>
  <value>/path/to/solr/auth/file</value>
</property>
{code}

That is, we specify multiple resources in the same sentry-site.xml file.  We could even use this in order to use the same provider resource for multiple services (assuming the models were identical -- otherwise we contradict #1).   For example, hive and sentry could use the same file by pointing sentry.hive.provider.resource and sentry.impala.provider.resource to the same file.

This model can work with using multiple sentry-site.xml files as well.  Let's say I wanted to use hive and solr but for hive I want to use the hadoop group mappings and for solr I want to use local group mappings.  I could specify two different sentry-site.xmls, where uses hadoop groups mappings and sets sentry.hive.provider.resource and another uses local group mappings and sets sentry.solr.provider.resource.  Alternatively, you could specify the service on the provider name, e.g. sentry.hive.provider and sentry.solr.provider in the same sentry-site.xml.

So in summary, my thoughts are as follows:
1) Only support one model per provider resource file (if two services use the same model, they can use the same provider resource file)
2) Don't restrict whether users can specify multiple or a single sentry-site.xml for multiple services.  To do this, the provider resource property name is parameterized by the service name, that is sentry.{servicename}.provider.resource.
3) The provider property name itself may or may not be parameterized by the service name, that is either sentry.provider or sentry.{service}.provider.  I don't have a strong feeling here but would lean towards it not being parameterized for simplicity (it seems rare that a user would want different providers for different services).

Thoughts?
                
> Multiple components and sentry-site.xml/providers
> -------------------------------------------------
>
>                 Key: SENTRY-14
>                 URL: https://issues.apache.org/jira/browse/SENTRY-14
>             Project: Sentry
>          Issue Type: Improvement
>            Reporter: Gregory Chanan
>
> This is related to the refactoring in SENTRY-9 and also renaming the properties in sentry-site.xml in SENTRY-4.
> The issue is what we support when users are using sentry in multiple services, e.g. hive, search, impala.
> Are they expected to use one sentry-site.xml for each service?  One sentry-site.xml for all services?  Either?
> I think the same questions that are relevant to the sentry-site.xml are also relevant to the provider resources.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira