[
https://issues.apache.org/jira/browse/YARN-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14065002#comment-14065002
]
Zhijie Shen commented on YARN-2247:
-----------------------------------
bq. The current implementation uses the standard http authentication for
hadoop. Users can set it to simple if they choose.
I was trying to make the point that when kerberos authentication is not used,
simple authentication is not implicitly set, isn't it? In this case, without
the authentication filter, we cannot identify the user via HTTP interface, such
that we cannot behave correctly for those operations that require the knowledge
of user information, such as submit/kill an application.
One step back, and let's look at the analog RPC interfaces. By default, the
authentication is SIMPLE, and at the server side, we can still identify who the
user is, such that the feature such as ACLs are is still working in the SIMPLE
case.
bq. For now I'd like to use the same configs as the standard hadoop http auth.
I'm open to changing them if we feel strongly about it in the future.
It's okay to keep the configuration same. Just think it out loudly. If so, you
may not want to add RM_WEBAPP_USE_YARN_AUTH_FILTER at all, and not load
YarnAuthenticationFilterInitializer programatically. The rationales behind them
are similar. Previously, I tried to add TimelineAuthenticationFilterInitializer
programmatically because I find the same http auth config applies to different
daemons, and I think it's annoying that at a single node cluster, I want to
config something only for timeline server, it will affect others. Afterwards, I
tried to make timeline server to use a set of configs with timeline-service
prefix. This is what we did for the RPC interface configurations.
bq. I didn't understand - can you explain further?
Let's take RMWebServices#getApp as an example. Previously we don't have (at
least don't know) the auth filter, such that we cannot detect the user.
Therefore, we don't check the ACLs, and simply get the application from
RMContext and return the user. Now, we have the auth filter, and we can
identify the user. Hence, it's possible for use to fix this API to only return
the application information to the user that has the access. This is also
another reason why I suggest to always have authentication filter on, whether
it is simple or kerberos.
bq. Am I looking at the wrong file?
This is the right file, but I'm afraid it is not the correct logic.
AuthenticationFilter accept null secret file. However, if we use
AuthenticationFilterInitializer to construct AuthenticationFilter, the null
case is denied. I previously open a ticket for this issue (HADOOP-10600).
> Allow RM web services users to authenticate using delegation tokens
> -------------------------------------------------------------------
>
> Key: YARN-2247
> URL: https://issues.apache.org/jira/browse/YARN-2247
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Varun Vasudev
> Assignee: Varun Vasudev
> Priority: Blocker
> Attachments: apache-yarn-2247.0.patch, apache-yarn-2247.1.patch,
> apache-yarn-2247.2.patch
>
>
> The RM webapp should allow users to authenticate using delegation tokens to
> maintain parity with RPC.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
