You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Alok Lal (JIRA)" <ji...@apache.org> on 2015/04/23 19:14:40 UTC

[jira] [Commented] (RANGER-420) Support for storing multi tenant audit data preserving the multi tenant nature in ranger schema

    [ https://issues.apache.org/jira/browse/RANGER-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14509386#comment-14509386 ] 

Alok Lal commented on RANGER-420:
---------------------------------

[~sethunr] I am trying to better understand your need.
- How does the system know about what belongs to different tenant?  If you got, say, a hook point to inspect the context (and result) of an authorization request before (or after) authorization would you be able to ascertain the tenant in your custom code?  If so then audit system might be able to consume that custom information and record that in the audit log.  Something external would then have to sift through the audit data and segregate it (or filter it on demand) for consumption.  All of this is just an idea, of course.  I am just trying to explore if a solution like this would work for you.
- Is this requirement for any particular product, e.g. hive, hdfs?

> Support for storing multi tenant audit data preserving the multi tenant nature in ranger schema
> -----------------------------------------------------------------------------------------------
>
>                 Key: RANGER-420
>                 URL: https://issues.apache.org/jira/browse/RANGER-420
>             Project: Ranger
>          Issue Type: Bug
>            Reporter: Sethukumar Ramachandran
>
> We have multi tenant data injestion, processing and analytics on the data in our HDP based hadoop platform. Ranger is used as a common audit framwork in this platform. But we are not able to segregate audit data based on tenant. It might be a future requirement for us to expose audit data through some custom portal to each tenant but at this point of time we are not able to do that because data in persistent storage in ranger schema do not accomodate this factor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)