You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Omkar Vinit Joshi (JIRA)" <ji...@apache.org> on 2013/05/17 01:37:16 UTC

[jira] [Updated] (YARN-694) AM uses the AMNMToken to authenticate all communication with NM. NM remembers and updates token across RM restart

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

Omkar Vinit Joshi updated YARN-694:
-----------------------------------

    Description: 
AM uses the AMNMToken to authenticate all the AM-NM communication.
NM will validate AMNMToken in below manner
* If AMNMToken is using current or previous master key then the AMNMToken is valid. In this case it will update its cache with this key corresponding to appId.
* If AMNMToken is using the master key which is present in NM's cache corresponding to AM's appId then it will be validated based on this.
* If AMNMToken is invalid then NM will reject AM calls.

Modification for ContainerToken
* At present RPC validates AM-NM communication based on ContainerToken. It will be replaced with AMNMToken. Also now onwards AM will use AMNMToken per NM (replacing earlier behavior of ContainerToken per container per NM).
* startContainer in case of Secured environment is using ContainerToken from UGI YARN-617; however after this it will use it from the payload (Container).
* ContainerToken will exist and it will only be used to validate the AM's container start request.

  was:
AM uses the AMNMToken to authenticate all the AM-NM communication.
NM will validate AMNMToken in below manner
* If AMNMToken is using current or previous master key then the AMNMToken is valid. In this case it will update its cache with this key corresponding to appId.
* If AMNMToken is using the master key which is present in NM's cache corresponding to AM's appId then it will be validated based on this.
* If AMNMToken is invalid then NM will reject AM calls.
Modification for ContainerToken
* At present RPC validates AM-NM communication based on ContainerToken. It will be replaced with AMNMToken. Also now onwards AM will use AMNMToken per NM (replacing earlier behavior of ContainerToken per container per NM).
* startContainer in case of Secured environment is using ContainerToken from UGI YARN-617; however after this it will use it from the payload (Container).
* ContainerToken will exist and it will only be used to validate the AM's container start request.

    
> AM uses the AMNMToken to authenticate all communication with NM. NM remembers and updates token across RM restart
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: YARN-694
>                 URL: https://issues.apache.org/jira/browse/YARN-694
>             Project: Hadoop YARN
>          Issue Type: Bug
>            Reporter: Omkar Vinit Joshi
>            Assignee: Omkar Vinit Joshi
>
> AM uses the AMNMToken to authenticate all the AM-NM communication.
> NM will validate AMNMToken in below manner
> * If AMNMToken is using current or previous master key then the AMNMToken is valid. In this case it will update its cache with this key corresponding to appId.
> * If AMNMToken is using the master key which is present in NM's cache corresponding to AM's appId then it will be validated based on this.
> * If AMNMToken is invalid then NM will reject AM calls.
> Modification for ContainerToken
> * At present RPC validates AM-NM communication based on ContainerToken. It will be replaced with AMNMToken. Also now onwards AM will use AMNMToken per NM (replacing earlier behavior of ContainerToken per container per NM).
> * startContainer in case of Secured environment is using ContainerToken from UGI YARN-617; however after this it will use it from the payload (Container).
> * ContainerToken will exist and it will only be used to validate the AM's container start request.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira