[
https://issues.apache.org/jira/browse/YARN-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682793#comment-13682793
]
Omkar Vinit Joshi commented on YARN-694:
----------------------------------------
Addressing below issues in this patch.
* NMTokenSecretManagerInNM remembers 2 things
** NMToken will not be updated in the oldKeyMap as a part of RPC -
retrievePassword call. It will be updated only if
*** it is a start container call using the proxy/connection/NMToken
*** and NMToken used for connection/proxy is using current master key Id or
previous master key id. (This is to enforce the client to use latest NMToken if
received on startContainer call).
* All requests will be authenticated using
** For start Container it will be either the current master key or previous
master key.
** For stop / get container status it will be authenticated either using
current/ previous / saved (oldKeysMap) key.
* All requests will be authorized but authorization will be different for
different type of requests.
** For start container request.
*** First check will be made to make sure that NMToken key id is using current
or previous key id.
*** Container Token passed in is correct. (retrievedPassword will be verified.)
*** ugi.getUserName is correct
*** RM Identifier is correct
*** ContainerToken is not expired.
*** ContainerToken passed in is for correct NodeManager, application
attempt(based on NMToken).
** For stop / get container request.
*** containerId passed in is correct w.r.t. the NMToken used for
authentication. This is to avoid checking status of / stopping containers
belonging to different application attempt.
*** If container could not be retrieved used will be notified accordingly.
** All application attempts started for application. This is required when we
need to clean up app attempt NMToken keys. Otherwise we will have to scan the
whole map (oldKeysMap).
* Add ContainerManagerProxy to cache connections/proxy per node manager. There
will be at max one connection per node manager. Number of proxies can be
configured using YarnConfiguration.NM_CLIENT_MAX_NM_PROXY_CONNECTIONS
* Api added in NMClient to set NMToken map which client can retrieve from
AMRMClient#getNMTokenMap.
* NMClientImpl updated to use NMToken and ContainerManagerProxy to communicate
with NM
Things remaining.
* Update TestContainerManagerSecurity to test NMToken changes. I will update
this soon.
> AM uses the NMToken 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 NMToken to authenticate all the AM-NM communication.
> NM will validate NMToken in below manner
> * If NMToken is using current or previous master key then the NMToken is
> valid. In this case it will update its cache with this key corresponding to
> appId.
> * If NMToken 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 NMToken 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 NMToken. Also now onwards AM will use NMToken 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
