Re: [DISCUSS] Sentry roadmap after 2.0

[Stephen Moist <mo...@cloudera.com>]

Sure here, you go 
https://issues.apache.org/jira/browse/SENTRY-2137 <https://issues.apache.org/jira/browse/SENTRY-2137>
https://issues.apache.org/jira/browse/SENTRY-2138 <https://issues.apache.org/jira/browse/SENTRY-2138>
https://issues.apache.org/jira/browse/SENTRY-2139 <https://issues.apache.org/jira/browse/SENTRY-2139>
https://issues.apache.org/jira/browse/SENTRY-2140 <https://issues.apache.org/jira/browse/SENTRY-2140>

I’ll leave the access control on database operations to someone else who knows more about that.


> On Jan 25, 2018, at 2:31 PM, Stephen Moist <mo...@cloudera.com> wrote:
> 
> A few things come to mind.
> 
> Improving and expanding on the capabilities of the Sentry CLI.  It would be good to see all the other services integrate with Sentry in a consistent way.  Along with be able to administer grants/roles/etc through a common framework rather than say beeline.
> 
> Improving documentation of Sentry’s integration, preferably with more examples of how to configure services.
> 
> Adding access control on database operations such as drop table, insert, delete from, update, etc.
> 
> I know for sure a feature we need is going to be tag based attribute control for Hive.
> 
> These last two ideas would need some reworking to make Sentry more flexible to support these, and I’m willing to lead up the latter for tags.
> 
>> On Jan 25, 2018, at 2:19 PM, Na Li <li...@cloudera.com> wrote:
>> 
>> https://issues.apache.org/jira/browse/SENTRY-2129 is create to track the
>> development activities for user-based privilege. I will add more sub-tasks
>> to it
>> 
>> On Thu, Jan 25, 2018 at 1:42 PM, Alexander Kolbasov <ak...@cloudera.com>
>> wrote:
>> 
>>> Agreed, making 2.1 with just user-level privileges improvements (plus set
>>> of accumulated bug fixes) sounds reasonable.
>>> 
>>> On Thu, Jan 25, 2018 at 11:41 AM, Alexander Kolbasov <ak...@cloudera.com>
>>> wrote:
>>> 
>>>> Looks like we have a consensus of doing user-level privileges
>>> improvements
>>>> for 2.1. Let's see whether anyone wants to add more content.
>>>> 
>>>> On Thu, Jan 25, 2018 at 11:38 AM, Na Li <li...@cloudera.com> wrote:
>>>> 
>>>>> Sasha,
>>>>> 
>>>>> I have looked into how to complete the user-based privilege for a while,
>>>>> and can commit to implement it. I can work with Kalyan to create a
>>> design
>>>>> doc for user-based privilege.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Lina
>>>>> 
>>>>> On Thu, Jan 25, 2018 at 1:35 PM, Na Li <li...@cloudera.com> wrote:
>>>>> 
>>>>>> Sasha,
>>>>>> 
>>>>>> The current user-based privilege missed some items:
>>>>>> 
>>>>>> 
>>>>>>  - Sentry policy has two service API: SentryPolicyService and
>>>>> SentryGenericPolicyService.
>>>>>>  The current implementation does not support user-based privilege
>>> for
>>>>>>  SentryGenericPolicyService
>>>>>>  - SENTRY-2091: User-based Privilege is broken by SENTRY-769. The
>>>>> patch
>>>>>>  is available for review.
>>>>>>  - Name Node need change to generate ACL using user privilege.
>>>>>>     - The full snapshot update only contains authorization to roles
>>>>>>     mapping and role to group mapping. *Need to add role to user
>>>>>>     mapping in* SentryStore.retrieveFullRoleImageCore
>>>>>>     - The delta updates are taken from table SENTRY_PERM_CHANGE,
>>> which
>>>>>>     does not distinguish group based permission or user based
>>>>> permission. No
>>>>>>     change is needed
>>>>>>     - The user changes to a role is not included when sending delta
>>>>>>     update from Sentry to NN. *Need to add AddUsers and DropUsers
>>>>>>     in TRoleChanges*.
>>>>>>     - Sentry only create ACL for group with ACL type
>>>>>>     as AclEntryType.GROUP. *Need to add code to create ACL with type
>>>>>>     as *AclEntryType.USER
>>>>>>     - SentryINodeAttributesProvider.checkPermission
>>>>>>        -> FSPermissionChecker.checkPermission ->
>>>>>>        SentryINodeAttributesProvider.getAclFeature
>>>>>>        -> SentryAuthorizationInfo.getAclEntries ->
>>> SentryPermissions.
>>>>>>        constructAclEntry
>>>>>>     - SentryStore.grantOptionCheck() has to be changed to find user
>>>>>>  level privilege.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Lina
>>>>>> 
>>>>>> On Thu, Jan 25, 2018 at 1:13 PM, Sergio Pena <
>>> sergio.pena@cloudera.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> There is a section on the Wiki about roadmap ideas and JIRAs already
>>>>>>> created:
>>>>>>> https://cwiki.apache.org/confluence/display/SENTRY/Sentry+
>>>>>>> Roadmap+and+ideas
>>>>>>> 
>>>>>>> I'm interested in having user-level privileges and special user
>>>>> privileges
>>>>>>> for objects owners.
>>>>>>> 
>>>>>>> I got this from the linked above:
>>>>>>> SENTRY-1073 User who creates a table should be granted all
>>>>> privileges on
>>>>>>> it by default
>>>>>>> SENTRY-1068 Allow user who created a table to have "with grant"
>>> over
>>>>>>> that
>>>>>>> table by default
>>>>>>> Creator of a table should have ownership of it (all privileges)
>>>>>>> Allow privileges to be granted to users directly
>>>>>>> 
>>>>>>> We should start planning the next Sentry 2.1 release based on the
>>>>> desired
>>>>>>> features. What about
>>>>>>> having 2 or 3 features on Sentry 2.1?
>>>>>>> 
>>>>>>> I vote for:
>>>>>>> - user-level privileges (currently grant user to role is only
>>>>> supported)
>>>>>>> - default user privileges for objects owners
>>>>>>> 
>>>>>>> Should we start a vote for new features for 2.1?
>>>>>>> 
>>>>>>> - Sergio
>>>>>>> 
>>>>>>> On Thu, Jan 25, 2018 at 12:46 PM, Kalyan Kumar Kalvagadda <
>>>>>>> kkalyan@cloudera.com> wrote:
>>>>>>> 
>>>>>>>> I would like to add something here.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  1. Current support for user-based-privileges allows admin to
>>>>> grant a
>>>>>>>>  role to user. Ideally, user-based-privileges feature should be
>>>>>>> allowing
>>>>>>>>  administrator to grant privileges to individual users directly.
>>>>>>>>     -  I'm working on this to come up with a scope doc.
>>>>>>>>     2. Currently sentry stores only grant privileges. This is not
>>>>>>>>  flexible. Let's say an administrator wants to grant role with
>>>>> select
>>>>>>> on
>>>>>>>> the
>>>>>>>>  all tables in a database except for couple to them, he needs to
>>>>>>>> individual
>>>>>>>>  select privileges for each table.
>>>>>>>>     1. Implementation should let you add a grant privilege on
>>>>> database
>>>>>>>>     and revokes privileges on the tables with in that database,
>>>>>>>>     2. This needs new look into privilege model that sentry
>>>>> currently
>>>>>>>> has.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -Kalyan
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -Kalyan
>>>>>>>> 
>>>>>>>> On Thu, Jan 25, 2018 at 12:16 PM, Alexander Kolbasov <
>>>>>>> akolb@cloudera.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Good point. There is some support for user-level privileges in
>>> 2.0
>>>>>>>> already
>>>>>>>>> - do you think that it is not sufficient and is missing some
>>> parts?
>>>>>>>>> 
>>>>>>>>> Is there anyone reading this who participated in the user-level
>>>>>>>> privileges
>>>>>>>>> in Sentry work done earlier? Is there any design doc for this?
>>>>>>>>> 
>>>>>>>>> - Alex
>>>>>>>>> 
>>>>>>>>> On Thu, Jan 25, 2018 at 10:11 AM, Na Li <li...@cloudera.com>
>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Sasha,
>>>>>>>>>> 
>>>>>>>>>> It would be nice to have more features for sentry.
>>>>>>>>>> 
>>>>>>>>>> For example, make user-based privileges working. So user can
>>>>> assign
>>>>>>>> user
>>>>>>>>>> directly to a role instead of through group.
>>>>>>>>>> 
>>>>>>>>>> Lina
>>>>>>>>>> 
>>>>>>>>>> On Thu, Jan 25, 2018 at 11:58 AM, Alexander Kolbasov <
>>>>>>>> akolb@cloudera.com
>>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Now that we have Sentry 2.0 release, I think it is a good
>>> time
>>>>> to
>>>>>>>> step
>>>>>>>>>> back
>>>>>>>>>>> from fixing bugs and immediate problems and start discussions
>>>>> on
>>>>>>>>> roadmap
>>>>>>>>>>> for Sentry going forward. Do we want to just keep it as is
>>> and
>>>>>>>> improve
>>>>>>>>>>> things here and there or we want to add new features?
>>>>>>>>>>> 
>>>>>>>>>>> What do people think?
>>>>>>>>>>> 
>>>>>>>>>>> - Alex
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>