hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allen Wittenauer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4006) YARN ATS Alternate Kerberos HTTP Authentication Changes
Date Sat, 21 May 2016 16:56:13 GMT

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

Allen Wittenauer commented on YARN-4006:
----------------------------------------

bq. Is the usecase description part of a proprietary solution that we don't want to expose
for some reason?

Yes.

bq. From what I can see, if a custom authentication handler (forget AltKerberos for a moment)
is configured than the TimelineAuthenticationFilterInitializer will not add it or the Pseudo
or Kerberos handlers to the FilterConfig.

... which would break folks who are using, e.g., SAML.  There are definitely handlers out
in the wild for all sorts of weird things.

bq. If we want to be able to use custom authentication handlers here than we need the change
proposed by this patch.

I'm left with the question of "why should timeline server be handled differently than every
other serving process in Hadoop?"  Even the 2NN allows for a custom authentication handler.
 It basically makes the TS seem like a significantly lower quality service if it can only
use two auth handlers when it only supports REST as a connection point!

bq. What are the different client types for this endpoint and how (if at all) does a proxy
come into play for each?

Automated processes that are outside the network to build reporting and what not.  They will
not have access to a kdc to use for authentication. A network hole will be punched that will
allow for IP redirection.  Also note that they can add custom user-agent strings...

bq. What would be examples of the non-kerberos side of the AltKerberos

JWT is definitely one of them. The other is an OTP string in a custom HTTP header. 

FWIW: I completely agree that this whole mess would go away if either AltKerberos was smarter
and/or there was a generic AuthenticationHandler hook that every daemon used.  But Hadoop
being Hadoop, the latter was never an option given how often individual teams working on individual
components seem to be stuck permanently in NIH mode.  "Oh, the NN needs to do this little
bit different for the 2NN" is what started the downward spiral here. :(



> YARN ATS Alternate Kerberos HTTP Authentication Changes
> -------------------------------------------------------
>
>                 Key: YARN-4006
>                 URL: https://issues.apache.org/jira/browse/YARN-4006
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: security, timelineserver
>    Affects Versions: 2.5.0, 2.6.0, 2.7.0, 2.5.1, 2.6.1, 2.8.0, 2.7.1, 2.7.2
>            Reporter: Greg Senia
>            Assignee: Greg Senia
>            Priority: Blocker
>         Attachments: YARN-4006-branch-trunk.patch, YARN-4006-branch2.6.0.patch, sample-ats-alt-auth.patch
>
>
> When attempting to use The Hadoop Alternate Authentication Classes. They do not exactly
work with what was built with YARN-1935.
> I went ahead and made the following changes to support using a Custom AltKerberos DelegationToken
custom class.
> Changes to: TimelineAuthenticationFilterInitializer.class
> {code}
>    String authType = filterConfig.get(AuthenticationFilter.AUTH_TYPE);
>     LOG.info("AuthType Configured: "+authType);
>     if (authType.equals(PseudoAuthenticationHandler.TYPE)) {
>       filterConfig.put(AuthenticationFilter.AUTH_TYPE,
>           PseudoDelegationTokenAuthenticationHandler.class.getName());
>         LOG.info("AuthType: PseudoDelegationTokenAuthenticationHandler");
>     } else if (authType.equals(KerberosAuthenticationHandler.TYPE) || (UserGroupInformation.isSecurityEnabled()
&& conf.get("hadoop.security.authentication").equals(KerberosAuthenticationHandler.TYPE)))
{
>       if (!(authType.equals(KerberosAuthenticationHandler.TYPE))) {
>         filterConfig.put(AuthenticationFilter.AUTH_TYPE,
>           authType);
>         LOG.info("AuthType: "+authType);
>       } else {
>         filterConfig.put(AuthenticationFilter.AUTH_TYPE,
>           KerberosDelegationTokenAuthenticationHandler.class.getName());
>         LOG.info("AuthType: KerberosDelegationTokenAuthenticationHandler");
>       } 
>       // Resolve _HOST into bind address
>       String bindAddress = conf.get(HttpServer2.BIND_ADDRESS);
>       String principal =
>           filterConfig.get(KerberosAuthenticationHandler.PRINCIPAL);
>       if (principal != null) {
>         try {
>           principal = SecurityUtil.getServerPrincipal(principal, bindAddress);
>         } catch (IOException ex) {
>           throw new RuntimeException(
>               "Could not resolve Kerberos principal name: " + ex.toString(), ex);
>         }
>         filterConfig.put(KerberosAuthenticationHandler.PRINCIPAL,
>             principal);
>       }
>     }
>  {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org


Mime
View raw message