sentry-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Towles (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SENTRY-2225) Generic Attribute Ingestion and Default Implementation
Date Fri, 11 May 2018 20:07:00 GMT

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

Brian Towles commented on SENTRY-2225:
--------------------------------------

Its not really about re-storage of attributes.  This is about collection of attributes (not
persistence in the long term) for use in other parts of Sentry.

So lets step back a bit and look at what an ABAC system needs, not just for the column masking
subsystem.  I think we have a bit of a disconnect on the relation of attributes to things like
access control and column masking.

The ability for a user to tie different sources of attributes into their access control decisions
and data presentation systems is very powerful and desired.  The [Guide to Attribute Based
Access Control (ABAC) Definition and Considerations|https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-162.pdf] talks
about this and is a good reference.

One of the key parts of this is that the Policy Information Point (PIP) is about the retrieval
of attributes and not the system of record for those attributes and the attributes themselves
could be volatile and potentially change frequently.  

For the general collection and aggregation of attributes I do not feel that the permanent
storage of attributes is needed or desired.  What the PIP side of this becomes is a attribute
collection, aggregation, and distribution source but not outright persistence.  It collects
the attributes from multiple sources based on the plugins developed for attribute collection. 
It aggregates this into a central attribute collection that it is able to distribute to
the bindings or Policy Decision Points (PDP).  This allows the access control engine or column
masking decision engine to have access to the attributes where the decision is being made
for speed and easy lookup.

The different attribute collection mechanisms would allow attributes that have a different
valid life spans to be taken into account. User or Subject level attributes might have a different
valid life span then HMS Object data.  It allows for the ability to implement different collection
patterns that may need to be put into place, push versus pull as needed by the system providing
the attributes.

Implementation of attribute collection can be done with a pluggable solution using Java Service
Loader SPI framework to allow for multiple attribute collection sources at one time.  It
would also provide set interfaces and loading mechanism for end user custom provided attribute
loading mechanisms as well as additional attribute collection that could come from the project.

Once attributes are ingested, column masking and other components in the system can make
use of the attributes in order to make decisions.  The aggregated set of attributes can be
distributed to the server or bindings, what ever is being the decision point and allow for
quick local access quickly.

The way I see it the initial sources can be the HMS Table Properties I mentioned above as
well as the Static File mechanism that could be used more for development and testing.

 

> Generic Attribute Ingestion and Default Implementation
> ------------------------------------------------------
>
>                 Key: SENTRY-2225
>                 URL: https://issues.apache.org/jira/browse/SENTRY-2225
>             Project: Sentry
>          Issue Type: Sub-task
>          Components: Core
>    Affects Versions: 2.1.0
>            Reporter: Anthony Young-Garner
>            Priority: Major
>              Labels: ABAC
>
> As discussed in the design document linked on SENTRY-2140, attributes and their mapping
to columns are created and stored in an external system. In order for Sentry to make masking
decisions based upon these attributes and mappings, this information must be ingested from
the external system. The scope of this Jira is to :
>  # implement the generic extensible framework by which different external systems may
contribute attributes (the specific details of the design are still under discussion on the
parent Jira; whether there is a full plugin model implemented in Sentry or whether the ingestion
process will run entirely external to Sentry and send the information to Sentry via Thrift
API is not yet decided).
>  # Implement at least one default implementation (whether this will be an example implementation
only for reference like a static text file or a full-featured implementation more suitable
for production use is under discussion) 



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

Mime
View raw message