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

Varun Vasudev commented on YARN-2247:
-------------------------------------

Uploaded new patch addressing review comments.

bq. 1. Like YARN-2228, you may want to always use 
YarnAuthenticationFilterInitializer to load the auth filter. When the security 
is enabled, use kerberos auth handler. Otherwise, use pseudo auth handler 
instead.

The current implementation uses the standard http authentication for hadoop. 
Users can set it to simple if they choose.

bq. 2. IMHO, the configs for different components' http authentication are 
better to have different prefix, such that we can easily make different configs 
for each component in a single config file. We have do the similar thing for 
YARN components' RPC kerberos authentication.

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.

bq. 3. The authentication thing has duplicated those of httpfs and timline 
sever again, which is fine now. However, after HADOOP-10771, RM may be able to 
reuse the dt+kerberos auth filter in hadoop-auth as well. We need to file a 
ticket to track it.

Agreed. I've filed YARN-2291 and YARN-2292 for that work.

bq. 4. With auth filter working, the other get APIs can also be benefited, such 
as getApp(s). We can do these actions with right users. Again, let's file a 
follow up ticket to deal with them.

I didn't understand - can you explain further?

{quote}
1. RM_WEBAPP_USE_YARN_AUTH_FILTER -> RM_WEBAPP_AUTH_FILTER and 
use-yarn-auth-filter -> auth-filter.enabled? And if the component is not RM 
only, should we not start with RM_ prefix, but use YARN_ prefix instead? Last 
but not least, if we always execute YarnAuthenticationFilterInitializer, the 
flag is not required then.
{noformat}
+  public static final String RM_WEBAPP_USE_YARN_AUTH_FILTER =
+      RM_PREFIX + "webapp.use-yarn-auth-filter";
{noformat}
{quote}

Fixed. Changed to RM_WEBAPP_DELEGATION_TOKEN_AUTH_FILTER and 
"webapp.delegation-token-auth-filter.enabled".

{quote}
2. Only this constructor will be called, won't it? Do we still need the other 
constructors?
{noformat}
+  public YarnAuthenticationFilterInitializer() {
+    this("hadoop.http.authentication.");
+  }
{noformat}
{quote}

Fixed.

{quote}
3. The authentication filter class actually accept null signature secret file, 
hence I think we should allow the null case
{noformat}
+    if (signatureSecretFile == null) {
+      throw new RuntimeException("Undefined property: "
+          + signatureSecretFileProperty);
+    }
{noformat}
{quote}

I looked up AuthenticationFilterInitializer and it does seem to check:
{noformat}
    String signatureSecretFile = filterConfig.get(SIGNATURE_SECRET_FILE);
    if (signatureSecretFile == null) {
      throw new RuntimeException("Undefined property: " + 
SIGNATURE_SECRET_FILE);      
    }
{noformat}
Am I looking at the wrong file?

In addition, I've also removed the use of AuthenticatedURL since there is a 
debate about its use.

> 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
>         Attachments: apache-yarn-2247.0.patch, apache-yarn-2247.1.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)

Reply via email to