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-2247) Allow RM web services users to authenticate using delegation tokens
Date Thu, 17 Jul 2014 15:13:04 GMT

    [ 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)

Mime
View raw message