You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Vrushali C (JIRA)" <ji...@apache.org> on 2017/07/20 06:00:00 UTC
[jira] [Comment Edited] (YARN-6820) Restrict read access to
timelineservice v2 data
[ https://issues.apache.org/jira/browse/YARN-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16094234#comment-16094234 ]
Vrushali C edited comment on YARN-6820 at 7/20/17 5:59 AM:
-----------------------------------------------------------
Thinking out loud:
Wondering if we can make use HBase visibility labels here for restricting read access.
https://hbase.apache.org/book.html#hbase.visibility.labels
Visibility labels can be used in conjunction with ACLs (if we need to in the future).
The labels have to be explicitly defined before they can be used in visibility labels. The label is only applied when data is written. The label is associated with a given version of the cell.
Visibility labels control can be used to only permit users associated with a given label to read or access cells with that label. For instance, we can label a cell by the group allowed to read data and only grant access to that label to that group. Visibility labels are implemented using Tags and allow us to store metadata on a per-cell basis. So when we scan, we pass in the group of the user querying as an authorization. If the group matches what is stored in hbase, we will get back those cells.
Groups can be granted visibility labels the same way as users. Groups are prefixed with an @ symbol. When checking visibility labels of a user, the server will include the visibility labels of the groups of which the user is a member, together with the user’s own labels.
was (Author: vrushalic):
Thinking out loud:
Wondering if we can make use HBase visibility levels here for restricting read access.
https://hbase.apache.org/book.html#hbase.visibility.labels
Visibility labels can be used in conjunction with ACLs (if we need to in the future).
The labels have to be explicitly defined before they can be used in visibility labels. The label is only applied when data is written. The label is associated with a given version of the cell.
Visibility labels control can be used to only permit users associated with a given label to read or access cells with that label. For instance, we can label a cell by the group allowed to read data and only grant access to that label to that group. Visibility labels are implemented using Tags and allow us to store metadata on a per-cell basis. So when we scan, we pass in the group of the user querying as an authorization. If the group matches what is stored in hbase, we will get back those cells.
Groups can be granted visibility labels the same way as users. Groups are prefixed with an @ symbol. When checking visibility labels of a user, the server will include the visibility labels of the groups of which the user is a member, together with the user’s own labels.
> Restrict read access to timelineservice v2 data
> ------------------------------------------------
>
> Key: YARN-6820
> URL: https://issues.apache.org/jira/browse/YARN-6820
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Reporter: Vrushali C
> Labels: yarn-5355-merge-blocker
>
> Need to provide a way to restrict read access in ATSv2. Not all users should be able to read all entities. On the flip side, some folks may not need any read restrictions, so we need to provide a way to disable this access restriction as well.
> Initially this access restriction could be done in a simple way via a whitelist of users allowed to read data. That set of users can read all data, no other user can read any data. Can be turned off for all users to read all data.
> Could be stored in a "domain" table in hbase perhaps. Or a configuration setting for the cluster. Or something else that's simple enough. ATSv1 has a concept of domain for isolating users for reading. Would be good to keep that in consideration.
> In ATSv1, domain offers a namespace for Timeline server allowing users to host multiple entities, isolating them from other users and applications. A “Domain” in ATSV1 primarily stores owner info, read and& write ACL information, created and modified time stamp information. Each Domain is identified by an ID which must be unique across all users in the YARN cluster.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org