Bryan,
Deny policies are currently available only in tag-based policies. To enable
for resource-based policies, say for Hive, servicedef of the Hive should be
updated to add the following option:
"options": {
"enableDenyAndExceptionsInPolicies":"true"
}
More details can be found in https://issues.apache.org/jira/browse/RANGER-874.
Thanks,
Madhan
On 4/8/16, 7:23 AM, "Bryan Bende" <[email protected]> wrote:
>Madhan,
>
>Thanks, I think I understand the difference now.
>
>Just so I understand, how do you create a deny policy?
>
>Thanks,
>
>Bryan
>
>On Fri, Apr 8, 2016 at 10:15 AM, Madhan Neethiraj <[email protected]> wrote:
>
>> Bryan,
>>
>> In this scenario, Ranger did not have a policy to either allow or deny
>> the requested access.
>>
>> Returning "isAccessDetermined=false, isAllowed=false” is necessary here
>> so that the callers can differentiate between Ranger actively denying a
>> request (via a deny policy) vs no policy to determine the access.
>>
>> Such a distinction is used by some plugins (like HDFS, YARN) to decide
>> whether to fallback to their native authorization or simply deny the
>> access. Other plugins (like Hive, Knox, Storm, Kafka) simply deny the
>> access when isAllowed=false - since there was no need/option to fallback
>> to their native authorization.
>>
>> Hope this helps.
>>
>> Madhan
>>
>>
>>
>> On 4/8/16, 6:48 AM, "Bryan Bende" <[email protected]> wrote:
>>
>> >Thanks Madhan, that is helpful.
>> >
>> >The scenario that is confusing me is this... I defined a policy for a
>> >resource, lets say "resource1", and I add "admin" user with "read"
>> >permission.
>> >
>> >Then I make an access request for "resource1" as the "admin" user for an
>> >action type of "write" (different action from policy above).
>> >
>> >This returns isAccessDetermined false and isAllowed false, which as you
>> >described means "Access not-determined".
>> >
>> >Why is isAccessDetermined false in this case? I thought this would have
>> >been isAccessDetermined true and isAllowed false because of the action not
>> >matching the permission.
>> >
>> >Thanks,
>> >
>> >Bryan
>> >
>> >
>> >
>> >On Thu, Apr 7, 2016 at 5:48 PM, Madhan Neethiraj <[email protected]>
>> wrote:
>> >
>> >> Bryan,
>> >>
>> >> Ranger policy model has been updated to be able to actively deny access.
>> >> This enhancement is already in the master and will be included in the
>> next
>> >> release - ranger-0.6.
>> >>
>> >> When an access is denied by Ranger, RangerAccessResult will have:
>> >> isAccessDetermined=true; isAllowed=false.
>> >>
>> >>
>> >> Here are the possible combinations:
>> >> --------------------------------------------------------------
>> >> | # | isAccessDetermined | isAllowed | Comment |
>> >> |------------------------|-----------|------------------------|
>> >> | 1 | True | True | Access Allowed |
>> >> |------------------------------------|------------------------|
>> >> | 2 | False | False | Access not-determined |
>> >>
>> >> |------------------------------------|------------------------|
>> >> | 3 | True | False | Access Denied |
>> >> |------------------------------------|------------------------|
>> >> | 4 | False | True | Invalid result |
>> >> --------------------------------------------------------------
>> >>
>> >>
>> >>
>> >>
>> >> In case of #2, the components can choose to:
>> >> - deny the access: this is done by Hive, Storm, Knox
>> >> - fallback to native access-control: this is done by HDFS, YARN
>> >>
>> >>
>> >> #4 is an invalid combination and this will not be returned by Ranger.
>> >>
>> >> Hope this helps.
>> >>
>> >> Madhan
>> >>
>> >> On 4/7/16, 1:21 PM, "Bryan Bende" <[email protected]> wrote:
>> >>
>> >> >Hello,
>> >> >
>> >> >What does isAccessDetermined mean on RangerAccessResult?
>> >> >
>> >> >From testing it seems like isAccessDetermined and isAllowed will both
>> be
>> >> >true when the user has access to the resource, and then they will both
>> be
>> >> >false in other cases.
>> >> >
>> >> >Is there ever a case where isAllowed is false, and isAccessDetermined
>> is
>> >> >true?
>> >> >
>> >> >Thanks,
>> >> >
>> >> >Bryan
>> >>
>> >>
>>
>>
