[
https://issues.apache.org/jira/browse/RANGER-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992808#comment-14992808
]
Yan commented on RANGER-606:
----------------------------
[~bganesan] Thanks for explanation. I'm sorry that I did not make my points,
which are rephrased/reorganised below clear. Please take a look.
1) I'm not sure about the role of Ranger Policies. If they represent the
current *state* of the security system, they should capture and persistent the
final state of the security system which will be consulted when the
authorization requests come in.
2) If the policies represent series of *actions* that are performed to
(re)establish the final state, then some rules need to be present to perform
these actions to ascertain the final state, either behind scenes at policy
creation/modification and persistent on disk, or at the authorization request
time, which would be very inefficient. Examples of such rules are execution in
time sequence, or priority-based (like priority of DENY over GRANT).
3) My guess is that the policies now represent the states, and not actions.
Please correct me if I am wrong here. This is also what FS(HDFS) and many SQL
products seem to adopt, namely their authorization decisions are based on
security states that are changed by actions that are *not* recorded after
execution once.
4) If policies are states, there could be various actions to work on them. The
actions do not need to be recorded or persistent after executed once. They
could be recorded, however, for future auditing/analysis purposes.
Given these points, my opinions in my last comment are:
1) Separate action clearly from states. Currently, the GRANT/REVOKE action is
actually realised through adding/removing the states, i.e., the policy items.
If more convenient ways of manipulating the states are desired, they might be
better to be added somewhere else from the Policies representing states.
2) The suggestion of using more fields as keys to guarantee privilege
uniqueness is really to guarantee the self-consistence of the "states" of the
security system. Otherwise either chaos would arise over time or some extra
conflict resolution mechanism would need to be introduced. This is not a novel
idea. Note that, for instance, FS ACLs are keyed on the (user/group, disk
entry) pair; while the SQL privileges are keyed on a triplet of (user/role,
object, privilege type(insert, select, update, ...)).
3) The "policy tagging" I referred last time is really not a new "policy type"
I introduced, but just my realisation of how the policy can be viewed
conceptually, even on the basis of the current Ranger codes.
4) An observation is that one challenge is to bridge the gaps among different
privilege systems in a least intrusive way. Notably HDFS and Hive have some
striking differences of their privilege models; they also share many common
features. If Ranger can bridge the gaps between HDFS and Hive further, for
which it has already done great I believe, it would become even more attractive.
The changes we could do, as I can perceive now, are:
1) To the minimum, add the sanity check to the policy items per policy. That
is, to add uniqueness check beyond just the check on "resource". This is
probably a must; otherwise, I am afraid, chaos might reign in the future. Note
that this will probably require disparate sanity checks for different service
types, particularly for HDFS and Hive, which is seemingly absent now.
2) Next, a "DENY" action, not a policy, is introduced to facilitate easy
removals of granted privileges. Different derivatives of DENY such as
DENY...EXCLUDE are optional.
3) Further closing/messaging of the remaining gaps among various privilege
models may be introduced. New concepts such as "default policies" might be
introduced. And further disparate policy evaluation might be needed as well.
4) Policy versioning may be introduced to support more advanced
auditing/analysis.
3) and 4) probably are long term goals, and of course are subject to future
discussions.
We are very interested in Ranger. Once the scopes are finalised and approved by
you, we will definitely help in implementation. Thanks.
> 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)
