ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tanping Wang <tanpi...@gmail.com>
Subject Re: Precedence of Multiple Security Policies in Ranger
Date Tue, 07 Jul 2015 05:25:21 GMT
Hi, Bosco,
Thanks for the detailed information!

I would certainly think having a precedence in calculating the security
policy would be a logical solution.  As you have listed that if revoke can
be evaluated first, that would be more clear.

In your fist example which is how Ranger implementation today, the "order"
seems to be an important factor.

What you are giving is:

Policy 1: User X has permission /apps/hive/** (recursive)
Policy 2: User X doesn¹t have permission to /apps/hive/my*
Policy 3: User X has permission to /apps/hive/my_customer_db

At this point:
User X has permission to:
/apps/hive/my_customer_db
/apps/hive/your_db

Let's say I switch the order of the policies to be:

Policy 1: User X has permission /apps/hive/** (recursive)
Policy 2: User X has permission to /apps/hive/my_customer_db
Policy 3: User X doesn¹t have permission to /apps/hive/my*

Then user X does NOT have permission to
/apps/hive/my_customer_db
but still has permission to
/apps/hive/your_db

Is this correct?  If so, what makes the "order" of Policy 1&2&3?  It is NOT
based on the time line of the policy creation as you pointed out.  So what
generates the "order" today for Ranger security policy?

Regards,
Tanping



On Thu, Jul 2, 2015 at 5:29 PM, Don Bosco Durai <bosco@apache.org> wrote:

> Tanping, what Balaji meant is, from the evaluation order the first policy
> that allowed access. We are continuously updating our evaluation logic to
> make it faster. So the evaluation order is not based on when the policy
> was created.
>
> Honestly, the order doesn¹t matter.  If policy ³A² and policy ³B² both
> gives ³read² permission to user ³X² for resource e.g.
> /apps/hive/warehouse/mydb², then it doesn¹t matter which policy gives the
> access, the user ³X² will be able to read the file.
>
> What are you looking for is the traditional way of managing permission.
> E.g.
> Policy 1: User X has permission /apps/hive/** (recursive)
> Policy 2: User X doesn¹t have permission to /apps/hive/my*
> Policy 3: User X has permission to /apps/hive/my_customer_db
>
> At this point:
> User X has permission to:
> /apps/hive/my_customer_db
> /apps/hive/your_db
>
> User X doesn¹t have permission to:
>
> /apps/hive/my_employee_db
>
>
> For this behavior, you need to execute the policies in the proper order.
> It is not an impossible task, but we felt that in typical Big Data
> deployment, you might have thousands of policies and if you have to
> maintain policy order, then it would remove the simplicity of policy
> management.
>
> As I mentioned before, we can consider a simplistic approach. Can I ask
> you, whether this implementation will address your use case?
>
> Policy n: User X doesn¹t have permissions to /apps/hive/my*
>
> Then regardless what other policies are there, User X won¹t have
> permissions to any folder/file with /apps/hive/my*. So in the above use
> case, you won¹t have permission to access /apps/hive/my_customer_db
>
> If this works for you, then we can evaluate all the negative/revokes
> first. And if the user as a ³revoke², then we simply reject the request.
> Else, we will proceed to see if the user has valid permission. This
> implementation will be easy to implement and also manage in real world.
>
> Let us know.
>
> Thanks
>
> Bosco
>
>
>
>
> On 7/3/15, 3:02 AM, "Tanping Wang" <tanpingw@gmail.com> wrote:
>
> >Hi, Balaji,
> >Thanks for the reply!
> >
> >When you say
> >>Ranger will provide access based on the first policy that permits the
> >access.
> >
> >The "First" refers the "oldest" policy that is created by time line?
> >Suppose I have two policy:
> >the first one was created in the year of 2014 which gives me every
> >permission
> >the second one was created in the year of 2015 which only gives me
> >some permission
> >
> >
> >No matter what I do, as long as I have the "oldest" security policy on, I
> >always have all permissions?
> >
> >If I understand this correctly, this is not very logical, isn't it?  There
> >should be some rules to follow in order to decide the precedence of
> >multiple policies.
> >
> >Regard,
> >Tanping
> >
> >
> >
> >On Thu, Jul 2, 2015 at 2:06 AM, Balaji Ganesan
> ><balaji.ganesan03@gmail.com>
> >wrote:
> >
> >> Tanping, Ranger is based on a permissive model. When Ranger is doing a
> >> policy evaluation, and if there are multiple policies for the user, then
> >> Ranger will provide access based on the first policy that permits the
> >> access. In Ranger 0.5, the audit log contains the policy id which
> >>granted
> >> the access, users can find out which policy provided the access to the
> >> user.
> >>
> >> On Thu, Jul 2, 2015 at 2:08 AM, Tanping Wang <tanpingw@gmail.com>
> wrote:
> >>
> >> > Hi, All,
> >> > I hope I made myself clear in my question.  If not, please let me
> >>know.
> >> > Basically I am asking:
> >> >
> >> > If I have multiple security policies set up for one component, HDFS,
> >>for
> >> > example, speaking of the end result of the permission,  is it a UNION
> >>of
> >> > the multiple security policies or is it a intersection or is it one
> >> > security policy takes the precedence?  How does Ranger decide?
> >> >
> >> > Regards,
> >> > Tanping
> >> >
> >> > On Wed, Jul 1, 2015 at 2:54 AM, Tanping Wang <tanpingw@gmail.com>
> >>wrote:
> >> >
> >> > > Hi,
> >> > > I would like to understand the precedence of multiple security
> >>policies
> >> > in
> >> > > Ranger.  For example,
> >> > > I have a global security policy for HDFS which have all the
> >>permissions
> >> > > open to a user, John
> >> > > I have a second security policy for HDFS which have /user/hive open
> >>to
> >> > the
> >> > > user, John.
> >> > >
> >> > > If I have both of them on, my understanding is John would have all
> >> > > permissions inherited from HDFS base Unix.
> >> > >
> >> > > How does the precedence get calculated?
> >> > >
> >> > > Regards,
> >> > > Tanping
> >> > >
> >> >
> >>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message