[
https://issues.apache.org/jira/browse/YARN-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655072#comment-13655072
]
Vinod Kumar Vavilapalli commented on YARN-613:
----------------------------------------------
bq. A keytab might be leaked due to weak permissions, or maybe it's not even
the keytab in the "official" path, but a copy a SE left sitting in their home
dir. So I might or might not be the yarn user with my stolen keytab. Assuming
you are the yarn user, I'm almost positive you can't get root with the
container executor - I last looked it had a hardcoded check to reject root.
My example of container-executor is wrong I agree. But my intention was in the
lines of - if some one steals a NM keytab, game is over anyways. Other examples
(at the least one correct one this time I hope) - Someone steals NM keytab,
they can do so many things:
- Starts a custom NM which advertises infinite resources with the RM and keep
heartbeating often and gobble up all containers
- 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
- Just keep heartbeating in a loop and bring down RM
You get the idea. Arguably there are minor checks we can do for the last two,
but not the first one. It is unsolvable in general.
Now coming to your specific solution. It looks like a good idea but needs minor
clarifications/extensions. Let see if I got what you are proposing:
- You have 1 NMToken per NM for the whole cluster and all AMs get the same
NMToken for a given node.
- Authorization for startContainer is via ContainerTokens
- Authorization for stopContainer is via AMToken.
Right? That works for startContainer() but won't for stopContainer().
- startContainer() is good: You use NMToken to authenticate to a node but can
only start-containers if you have a valid ContainerToken
- stopContainer() needs a little more help: Again authentication with NMToken
is good. But we can't just rely on NMToken to allow access to an AM to stop a
container. Let's start with a simple authz with no acls - AMs can only kill the
containers that they own. To do this, NM needs to check what the APPID is for
this App and then allow access for the corresponding containers. Now in order
to avoid AMs faking AppIds, the NMTokenIdentifier should have NodeId, AppId,
and may be also user-name for doing more complex app-acls. If we do that, when
an NM get a stopContainer, it get the user-name and appid and can perform the
necessary authorization.
So in sum, yes, NMToken sounds a good idea, but we need it to have per AM
information.
Given above, we should perhaps call this AMNMToken and rename the current
AMToken to be AMRMToken.
Does that sound good?
> 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
