[
https://issues.apache.org/jira/browse/MAPREDUCE-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272751#comment-13272751
]
Siddharth Seth commented on MAPREDUCE-3943:
-------------------------------------------
Thanks for taking a look Daryn.
The patch requires MAPREDUCE-3940 to be applied first (if that still applies).
bq. It feels a bit contorted for the RM to have a pb message with the current
and prior key (ie. it's limited), which is the root of the 2X key roll problem.
With the patch the way it is, having the RM transmit a single key and the NM
remembering N-many keys is probably "less bad"...?
Current and prior keys are only sent during nodeRegistration - in case a node
registers in the window where the RM has generated a new key but hasn't started
using it yet. nodeHeartbeat calls only send the latest key.
The NM remembers 2 keys - which is what causes the 2x key roll problem.
Remembering additional keys on the NM needs to be controlled - older keys can't
be used to startContainers. The half patch I mentioned earlier - would get the
NM to remember additional keys for containers which have already been started.
Will incorporate that into this patch.
bq. Passing the shared secret keys in "plaintext" in heartbeats is a bit
troubling in general. More concerning is the direction of the data flow: RM
generates secret and gives it to the NMs. A rogue or compromised NM can
intercept a key which I believe can be used to generate tokens for other NMs.
If true, doesn't that put the entire cluster at risk?
bq. Conceptually, the RM should simply request a token from the NM and pass the
token along to the AM so it can contact the NM. It that's too expensive, it
seems like the key exchange should be inverted: NMs generate their own secret,
and provide that secret to the RM. A compromised node cannot damage the entire
cluster.
Having NMs generate keys can get expensive.NMs generate keys and provide them
to the RM can be achieved by having the RM generate individual keys per NM. I'd
prefer dealing with that in a separate jira - since it's a reasonably
independent change.
> RM-NM secret-keys should be randomly generated and rolled every so often
> ------------------------------------------------------------------------
>
> Key: MAPREDUCE-3943
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-3943
> Project: Hadoop Map/Reduce
> Issue Type: Sub-task
> Components: mrv2, security
> Affects Versions: 0.23.0
> Reporter: Vinod Kumar Vavilapalli
> Assignee: Vinod Kumar Vavilapalli
> Attachments: MAPREDUCE-3943-20120416.txt, MR3943.txt
>
>
> - RM should generate the master-key randomly
> - The master-key should roll every so often
> - NM should remember old expired keys so that already doled out
> container-requests can be satisfied.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
