Details
-
Sub-task
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
Incompatible change, Reviewed
Description
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.
Attachments
Attachments
Issue Links
- blocks
-
YARN-613 Create NM proxy per NM instead of per container
- Closed
-
YARN-739 NM startContainer should validate the NodeId
- Closed
- breaks
-
YARN-854 App submission fails on secure deploy
- Closed
- is blocked by
-
YARN-692 Creating NMToken master key on RM and sharing it with NM as a part of RM-NM heartbeat.
- Closed
-
YARN-693 Sending NMToken to AM on allocate call
- Closed
-
YARN-639 Make AM of Distributed Shell Use NMClient
- Closed
- is related to
-
YARN-1433 ContainerManagementProtocolProxy doesn't have the retry policy
- Open
- relates to
-
YARN-870 Node manager is no longer required to store ContainerToken as it is required only during startContainer call.
- Resolved
-
YARN-1189 NMTokenSecretManagerInNM is not being told when applications have finished
- Closed