Yongjun Zhang commented on YARN-3021:

If we can have a way to tell YARN not to renew a token, and the client either 
wants to just to use the lifetime of the token, or the client can renew itself 
before the job finish, that will solve the problem. One possible solution is to 
add a new parameter when submitting a job, or ro add a field in the job context.
However, assume we have the API to let YARN not to renew the token, YARN might 
still want to check whether a token submitted from client is valid. Currently 
the validity checking is done in the renewal code described in
and Harsh's patch tries to fix. In other words, the renewal code serves as both 
validating and renewing the token. There seems to be no dedicated API to check 

In the scenario Harsh described, even if we have dedicated API to check token 
validity, the check would fail too because realm A and B don't have trust, even 
though the token is valid from realm B's point of view.

So my question is, should YARN support running a job without validating a 
token? (Though MR1 "support" this because the token renewal is asynchronous as 
Harsh pointed out). 


> YARN's delegation-token handling disallows certain trust setups to operate 
> properly
> -----------------------------------------------------------------------------------
>                 Key: YARN-3021
>                 URL: https://issues.apache.org/jira/browse/YARN-3021
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.3.0
>            Reporter: Harsh J
>         Attachments: YARN-3021.patch
> Consider this scenario of 3 realms: A, B and COMMON, where A trusts COMMON, 
> and B trusts COMMON (one way trusts both), and both A and B run HDFS + YARN 
> clusters.
> Now if one logs in with a COMMON credential, and runs a job on A's YARN that 
> needs to access B's HDFS (such as a DistCp), the operation fails in the RM, 
> as it attempts a renewDelegationToken(…) synchronously during application 
> submission (to validate the managed token before it adds it to a scheduler 
> for automatic renewal). The call obviously fails cause B realm will not trust 
> A's credentials (here, the RM's principal is the renewer).
> In the 1.x JobTracker the same call is present, but it is done asynchronously 
> and once the renewal attempt failed we simply ceased to schedule any further 
> attempts of renewals, rather than fail the job immediately.
> We should change the logic such that we attempt the renewal but go easy on 
> the failure and skip the scheduling alone, rather than bubble back an error 
> to the client, failing the app submission. This way the old behaviour is 
> retained.

This message was sent by Atlassian JIRA

Reply via email to