[
https://issues.apache.org/jira/browse/YARN-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111694#comment-16111694
]
Jason Lowe commented on YARN-6820:
----------------------------------
Thanks for the patch!
I'd prefer if the whitelist behaved more consistently with other access
whitelists in YARN, e.g.: yarn.admin.acl. Those support both an optional,
comma-separated list of users and an optional, comma-separated list of groups.
That way if the users that we want to add are all in an existing Unix group we
can just add the group directly rather than duplicate that list in the read
whitelist config. The AccessControlList class makes this pretty easy.
Rather than manually add the permission check to each and every REST API which
has traditionally been error prone, would it be simpler in this case to install
a web filter that does the access check and throws the error? Unlike a "real"
ACL setup where we want to see what type of operation they're doing to
determine whether they have access, in this case we want to block _anything_
they're doing if they're not on the whitelist, correct?
> 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
> Assignee: Vrushali C
> Labels: yarn-5355-merge-blocker
> Attachments: YARN-6820-YARN-5355.0001.patch
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
