[
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)
