hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vrushali C (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-6820) Restrict read access to timelineservice v2 data
Date Thu, 10 Aug 2017 19:42:00 GMT

    [ https://issues.apache.org/jira/browse/YARN-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122188#comment-16122188

Vrushali C commented on YARN-6820:

Thanks [~jlowe]
bq.  don't see why we would sometimes want to get the user via the principal and sometimes
Yes, I was initially using getRemoteUser since the webservices in timeline service are invoking
that. But the RM webservices seem to be using the getUserPrincipal.

I looked up in the Java EE documentations for 6 and 7 regarding the behavior around getRemoteUser
and getUserPrincipal. 



Both 6 and 7 seem to say the same thing:

getRemoteUser, which determines the user name with which the client authenticated. The getRemoteUser
method returns the name of the remote user (the caller) associated by the container with the
request. If no user has been authenticated, this method returns null.

getUserPrincipal, which determines the principal name of the current user and returns a java.security.Principal
object. If no user has been authenticated, this method returns null. Calling the getName method
on the Principal returned by getUserPrincipal returns the name of the remote user.

It looks like getUserPrincipal.getName will get the name of the remote user, so I think both
calls that timeline service is making, will return the same thing. That said, I can still
file a jira to ensure the webservices code (unrelated to this patch) will invoke the getUserPrincipal
so that we have consistency across the codebase.  What do you think? 

> 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, YARN-6820-YARN-5355.002.patch, YARN-6820-YARN-5355.003.patch,
YARN-6820-YARN-5355.004.patch, YARN-6820-YARN-5355.005.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

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message