[
https://issues.apache.org/jira/browse/YARN-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656029#comment-13656029
]
Daryn Sharp commented on YARN-613:
----------------------------------
Agreed that a rogue NM is impossible to prevent entirely, but we can contain
the damage a NM can do other than DOS attacks. On that tangent, it would
probably be a good idea to automatically blacklist nodes that are misbehaving
by spamming heartbeats.
bq. Starts a custom NM which advertises infinite resources [...]
Shouldn't there be a configurable upper bound on advertised resources, if
nothing else to prevent a misconfigured NM from harming the cluster?
bq. Act sane, gobble up some containers, get some containers, get app-ids,
guess and construct new container-ids and send false reports about other
containers of the app which are running on other nodes
Are there really no checks to prevent this sort of malicious/buggy behavior
today??
bq. You have 1 NMToken per NM for the whole cluster and all AMs get the same
NMToken for a given node.
No, I meant per-NM tokens. I left out the implicit assumption the NM token
contains the NM's hostname to ensure the AM isn't using the token for the wrong
host.
bq. the NMTokenIdentifier should have NodeId, AppId, and may be also user-name
for doing more complex app-acls
This would work fine. The contrast is NM tokens become per-node per-AM tokens,
whereas my suggestion is per-node NM tokens used for start container. While
the NM token could be used for start/stop, the launch context could contain the
AM and/or container token (which is already there) as later auth for
status/stop calls. The AM token may be preferable to maintain a single AM->NM
connection for status/stop. The benefit of passing the AM token in the launch
request is the NM won't later need the AM's secret since it knows exactly which
token to allow.
Again though, your approach will work fine as well.
bq. Given above, we should perhaps call this AMNMToken and rename the current
AMToken to be AMRMToken.
Agreed. In any case, renaming AM to AMRMToken makes it easier to understand
the purpose of the token. It would be nice if the kind field is also changed.
> Create NM proxy per NM instead of per container
> -----------------------------------------------
>
> Key: YARN-613
> URL: https://issues.apache.org/jira/browse/YARN-613
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Bikas Saha
> Assignee: Omkar Vinit Joshi
>
> Currently a new NM proxy has to be created per container since the secure
> authentication is using a containertoken from the container.
--
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
