[
https://issues.apache.org/jira/browse/RANGER-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711571#comment-14711571
]
Madhan Neethiraj commented on RANGER-606:
-----------------------------------------
[~bganesan] Good usecases to discuss in concrete.
>> If a Hive policy has columns excluded in the resources section, and we deny
>> the user for this set of resources, what does that really mean? It would
>> mean user is denied for all columns except the column excluded in resource
>> section. A layman policy creator will really need to think through before
>> constructing a policy
Lets consider a Hive policy with table specification as "value=test*;
isExcludes=true". Clearly, this policy is for tables whose name do not start
with "test". If the policy type is allow, it will allow access to all tables
whose name do not start with "test". If the policy type is deny, it will deny
access to all tables whose name do not start with "test". I think this is
intuitive enough. If the users can't find cause of an unexpected allow or deny
(i.e. assuming a layman policy creator who didn't know what he/she is doing),
Ranger audit can be used to find the policy that decided to allow or deny.
>> In HDFS, if introduce a deny in the policy, does that mean we do not fall
>> back to HDFS permissions? What are the implications of that for Falcon and
>> other components which set permissions natively?
It will help to think this way: fallback to native authorization (for example
HDFS ACLs) is done *only* when Ranger policies can not determine the
authorization - either allow or deny. That is, if a Ranger policy explicitly
denies or allows access to a resource, there will not be any fallback to native
authorization.
>> The point is resource level deny introduces another layer of complexity, and
>> we should not be unleashing it on Ranger users unless there is a clear value
>> proposition.
I agree here. My concern is burdening the infrastructure for piecemeal
requirements, which will introduce a ton of unnecessary complexity - both in
terms of implementation, API access and migration. Adding such patch works
(i.e. just implement to address x requirement today and y tomorrow, z in next
few weeks...) will cost us and users across releases in having to deal with
migration. It will be critical to discuss in terms to concepts that the Ranger
policy model needs to support instead of requirements that trickle every day.
> Add support for deny policies
> ------------------------------
>
> Key: RANGER-606
> URL: https://issues.apache.org/jira/browse/RANGER-606
> Project: Ranger
> Issue Type: Bug
> Components: admin, plugins
> Affects Versions: 0.5.0
> Reporter: Madhan Neethiraj
> Assignee: Madhan Neethiraj
> Fix For: 0.5.0
>
>
> Currently Ranger supports creation of policies that can allow access when
> specific conditions are met (for example, resources, user, groups,
> access-type, custom-conditions..). In addition to this, having the ability to
> create policies that deny access for specific conditions will help address
> many usecases, like:
> - deny access for specific users/groups/ip-addresses/time-of-day
> - deny access when specific conditions are met - like
> resources/users/groups/access-types/custom-conditions
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
