hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varun Vasudev (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (YARN-2247) Allow RM web services users to authenticate using delegation tokens
Date Mon, 21 Jul 2014 06:36:39 GMT

     [ https://issues.apache.org/jira/browse/YARN-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Varun Vasudev updated YARN-2247:

    Attachment: apache-yarn-2247.3.patch

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.


Got it. I've added support for simple auth in the default case. I also spoke with [~vinodkv]
offline and we felt that in secure mode the default static user should not be allowed to submit
jobs. I made that change as well.

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.

I see your point but I don't think forcing users to replicate existing configs makes sense
at this point. The RM web interfaces are already controlled by the common http auth configs
and I'd like to preserve that behaviour.

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.

Agree with your tickets.

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

Thanks for pointing that out. Fixed.

> 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

View raw message