Simplifying Sentry model

[Alexander Kolbasov <ak...@cloudera.com>]

I was wondering why our Sentry Server, which is, essentially, a wrapper
around the storage layer is so complex. It seems that a lot of complexity
(putting HDFS sync aside) is coming from the fact that the Sentry Server
knows too much about HMS semantics. For example, the only reason we need to
have synchronization between HMS and Sentry in Sentry HA is because Sentry
actually modifies permissions on tables and databases when some permissions
actions are performed.  Also it is very smart about understanding composite
ALL permissions.

I think we can simplify this model a *LOT* if  we separate the knowledge.
Sentry Server should be just a storage of information - it shouldn't have
any smartness in it. It should store roles an groups and permissions and
allow callers to store and modify these objects but it shouldn't understand
what they actually mean. It is up to the consumers (HMS, for example) to
make smart decisions about what is ALL permissions, or what should change
when a table is dropped. Sentry server shouldn't be in the business of
changing permissions on drop table event - HMS should do that instead.

This will also simplify us to use one truly generic model for HMS and all
other components - the model would be just the data representation for
roles groups and permissions.

I think this will untangle a lot of the current complexity mess.

Any thoughts on this?

- Alex

Re: Simplifying Sentry model

[Sergio Pena <se...@cloudera.com>]

I shared the same opinion about Sentry server with you Sasha.
Although, probably the contributors with more time experience on Sentry
would know the reason for the design approach of the Sentry server.


On Sat, Jun 10, 2017 at 8:35 PM, Na Li <li...@cloudera.com> wrote:

> Sasha,
>
> I agree.
>
> There several issues in current sentry solution.
>
> 1) Changing permission on one table could cause update on wild card
> permission on database.
>
> We can use policy-based approach to specify permission. So updating one
> policy does not require update of other policies.
>
> When determine the permissions, all match policies are applied in order of
> priority. The highest policy has the final say.
>
> 2) Sentry update the query. It makes it hard to support different types of
> DB.
>
> As you mentioned, Sentry service should return the permission info to
> caller, and caller should update query to enforce the permission. The
> caller can be Sentry client plugin, but not part of Sentry service.
>
>
> Thanks,
>
> Lina
>
> Sent from my iPhone
>
> > On Jun 10, 2017, at 2:26 AM, Alexander Kolbasov <ak...@cloudera.com>
> wrote:
> >
> > I was wondering why our Sentry Server, which is, essentially, a wrapper
> around the storage layer is so complex. It seems that a lot of complexity
> (putting HDFS sync aside) is coming from the fact that the Sentry Server
> knows too much about HMS semantics. For example, the only reason we need to
> have synchronization between HMS and Sentry in Sentry HA is because Sentry
> actually modifies permissions on tables and databases when some permissions
> actions are performed.  Also it is very smart about understanding composite
> ALL permissions.
> >
> > I think we can simplify this model a LOT if  we separate the knowledge.
> Sentry Server should be just a storage of information - it shouldn't have
> any smartness in it. It should store roles an groups and permissions and
> allow callers to store and modify these objects but it shouldn't understand
> what they actually mean. It is up to the consumers (HMS, for example) to
> make smart decisions about what is ALL permissions, or what should change
> when a table is dropped. Sentry server shouldn't be in the business of
> changing permissions on drop table event - HMS should do that instead.
> >
> > This will also simplify us to use one truly generic model for HMS and
> all other components - the model would be just the data representation for
> roles groups and permissions.
> >
> > I think this will untangle a lot of the current complexity mess.
> >
> > Any thoughts on this?
> >
> > - Alex
> > --
> > You received this message because you are subscribed to the Google
> Groups "sentry-ha" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sentry-ha+unsubscribe@cloudera.com.
> > To post to this group, send email to sentry-ha@cloudera.com.
> > To view this discussion on the web visit https://groups.google.com/a/
> cloudera.com/d/msgid/sentry-ha/CAGGNey3TaY_KXj--aC3%
> 3D7LU2ixUoeJijyUuvf9tn7h37mVs9Gg%40mail.gmail.com.
>

Re: Simplifying Sentry model

[Na Li <li...@cloudera.com>]

Sasha,

I agree.

There several issues in current sentry solution.

1) Changing permission on one table could cause update on wild card permission on database. 

We can use policy-based approach to specify permission. So updating one policy does not require update of other policies. 

When determine the permissions, all match policies are applied in order of priority. The highest policy has the final say. 

2) Sentry update the query. It makes it hard to support different types of DB. 

As you mentioned, Sentry service should return the permission info to caller, and caller should update query to enforce the permission. The caller can be Sentry client plugin, but not part of Sentry service.


Thanks,

Lina

Sent from my iPhone

> On Jun 10, 2017, at 2:26 AM, Alexander Kolbasov <ak...@cloudera.com> wrote:
> 
> I was wondering why our Sentry Server, which is, essentially, a wrapper around the storage layer is so complex. It seems that a lot of complexity (putting HDFS sync aside) is coming from the fact that the Sentry Server knows too much about HMS semantics. For example, the only reason we need to have synchronization between HMS and Sentry in Sentry HA is because Sentry actually modifies permissions on tables and databases when some permissions actions are performed.  Also it is very smart about understanding composite ALL permissions.
> 
> I think we can simplify this model a LOT if  we separate the knowledge. Sentry Server should be just a storage of information - it shouldn't have any smartness in it. It should store roles an groups and permissions and allow callers to store and modify these objects but it shouldn't understand what they actually mean. It is up to the consumers (HMS, for example) to make smart decisions about what is ALL permissions, or what should change when a table is dropped. Sentry server shouldn't be in the business of changing permissions on drop table event - HMS should do that instead.
> 
> This will also simplify us to use one truly generic model for HMS and all other components - the model would be just the data representation for roles groups and permissions.
> 
> I think this will untangle a lot of the current complexity mess.
> 
> Any thoughts on this?
> 
> - Alex
> -- 
> You received this message because you are subscribed to the Google Groups "sentry-ha" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sentry-ha+unsubscribe@cloudera.com.
> To post to this group, send email to sentry-ha@cloudera.com.
> To view this discussion on the web visit https://groups.google.com/a/cloudera.com/d/msgid/sentry-ha/CAGGNey3TaY_KXj--aC3%3D7LU2ixUoeJijyUuvf9tn7h37mVs9Gg%40mail.gmail.com.