[
https://issues.apache.org/jira/browse/YARN-9385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792193#comment-16792193
]
Eric Yang commented on YARN-9385:
---------------------------------
[~tlipcon] I missed your other point in YARN-9385 earlier that if we should
make decision based on UserGroupInformation.isSecurityEnabled or
hadoop.http.authentication.type. This is a problem in Hadoop that it allows
Kerberos deployed cluster to use insecure HTTP UI because
hadoop.security.authentication and hadoop.http.authentication.type are
independent config. If API service left unsecured by spnego or JWT token, YARN
will have a major security leak. We made change to getRMWebAddress
isSecurityEnabled() for ApiServiceClient to cover different authentication
mechanism that all have security enabled. In the absolute no security
deployment on http channel, then we send user.name parameter. Changing
appendUserNameIfRequired to use UGI.isSecurityEnabled() is not 100% accurate on
all cluster configurations. We most likely want to nullified
hadoop.http.authentication.type setting to improve security. Until
hadoop.http.authentication.type setting is removed, we have no choice but
checking both flags. This is the reason that code is written this way.
> YARN Services with simple authentication doesn't respect current UGI
> --------------------------------------------------------------------
>
> Key: YARN-9385
> URL: https://issues.apache.org/jira/browse/YARN-9385
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: security, yarn-native-services
> Reporter: Todd Lipcon
> Assignee: Eric Yang
> Priority: Major
> Attachments: YARN-9385.001.patch
>
>
> The ApiServiceClient implementation appends the current username to the
> request URL for "simple" authentication. However, that username is derived
> from the 'user.name' system property instead of the current UGI. That means
> that username spoofing via the 'HADOOP_USER_NAME' variable doesn't take
> effect for HTTP-based calls in the same manner that it does for RPC-based
> calls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
