hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zhijie Shen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-2228) TimelineServer should load pseudo authentication filter when authentication = simple
Date Thu, 10 Jul 2014 14:20:04 GMT

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

Zhijie Shen commented on YARN-2228:

Vinod, thanks for your review. Please check my response bellow.

bq. Not sure if we can rename this to be better, but if possible we should.

"yarn.timeline-service" is trying to indicate which component the configurations are related
to, and "http.authentication.xxxx" is to be as close as to the original "hadoop.http.authentication.xxxx".
Does it make sense?

bq. After this patch, owner should never be empty, right? We can reject requests when we cannot
figure out the submission user.

Via TimelineClient, the owner is always set no matter it is pseudo or kerberos authentication.
However, users can choose to walk around TimelineClient and post entities to the timeline
server on top of the REST API directly. Personally, I prefer to accept anonymous user, in
case some users want to ignore security at all. For example, when testing the functionality
stuff, users may not want to append "user.name=xxxx" every time they compose a URL.

bq. I am not able find the magic that is automatically putting the PseudoAuthFilter into the
configuration. It also seems like TimelineAuthenticationFilterInitializer is always added
irrespective of security.

It is based on the agreement that ACLs need to work in insecure mode (i.e. type = simple)
as well. Given this agreement, I need always to use TimelineAuthenticationFilterInitializer
to load TimelineAuthenticationFilter, which will extract the user information from the request.
When type = simple, the user information comes from the URL param. On the other hand, if we
don't load the authentication filter in insecure mode, the timeline server is unable to know
the user of a request.

By default, the authentication type is "simple", the parent class of TimelineAuthenticationFilter
(i.e., AuthenticationFilter) is going to load PseudoAuthenticationFilter. The magic is within

bq. It doesn't seem like we had tests to validate delegationtoken based access to TimelineServer?

The whole authentication part is lacking test cases. Given the work of HADOOP-10799, we may
take advantage of DT authentication stack in common, which will mitigate the problem, because
the relevant test cases are promoted to common together with DT authentication stack. After
that, we can evaluate what are missing UTs for the scenario of the timeline server. Now let's
just file a ticket to track the UT stuff. How do you think?

Please suggest on these points further. For the remaining comments, I've addressed them in
the newly uploaded patch.

> TimelineServer should load pseudo authentication filter when authentication = simple
> ------------------------------------------------------------------------------------
>                 Key: YARN-2228
>                 URL: https://issues.apache.org/jira/browse/YARN-2228
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Zhijie Shen
>            Assignee: Zhijie Shen
>         Attachments: YARN-2228.1.patch, YARN-2228.2.patch, YARN-2228.3.patch
> When kerberos authentication is not enabled, we should let the timeline server to work
with pseudo authentication filter. In this way, the sever is able to detect the request user
by checking "user.name".
> On the other hand, timeline client should append "user.name" in un-secure case as well,
such that ACLs can keep working in this case. 

This message was sent by Atlassian JIRA

View raw message