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

Anthony Young-Garner commented on SENTRY-2140:
----------------------------------------------

{quote}Why is the cache needed? Sentry does not have a cache for RBAC rules, 
why is needed for ABAC?
{quote}
Another architectural reason for the cache (however it is implemented) is that 
the source of record for attributes is external to Sentry. Attributes are being 
ingested into Sentry from a file. The file is the source of record from the 
perspective of Sentry. The lifecycle (create, update, delete) of attributes 
occurs in the file, external to Sentry. So any representation of attributes 
within Sentry (whether in memory or persistent) is functionally a copy rather 
than the original representation. If we wanted to be strict as possible, we 
would read from the file every time the attribute data is needed, but this is 
very inefficient. The in-memory and/or persistent representations of attributes 
within Sentry are then, by definition, a cache – regardless of how implemented.

> Attribute based access control
> ------------------------------
>
>                 Key: SENTRY-2140
>                 URL: https://issues.apache.org/jira/browse/SENTRY-2140
>             Project: Sentry
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Steve Moist
>            Priority: Major
>         Attachments: Sentry ABAC Proposal v1.1.pdf, Sentry ABAC Proposal.pdf
>
>
> As a user, I want to have finer grain control over which users/roles can view 
> data in Hive.  Some information such as Social Security Number is considered 
> very confidential information.  I want to be able to tag columns in Hive with 
> "attributes" that prevent users/roles from not accessing or seeing the data.  
> For users/roles that have that attribute, they should be able to see that 
> information.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to