[
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 AuthenticationFilter#init.
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
(v6.2#6252)
