[
https://issues.apache.org/jira/browse/YARN-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647263#comment-13647263
]
Vinod Kumar Vavilapalli commented on YARN-613:
----------------------------------------------
bq. I just have general concerns with assuming the entire hadoop environment is
trusted and thus introducing weaknesses at a global level . Ex. A weakness is
introduced every time one entity shares a secret to validate a token created by
another entity. Compromising one of hundreds or thousands of node shouldn't put
the entire cluster at risk.
Agree with you in general. Read on.
bq. If I can gain access to one NM host and its keytab, I believe I can
secretly launch a malicious NM?
That is true in general. And I am not sure how we can even contain such a
break-in. I suppose going the way of DataNode to start the server on privileged
ports will contain it [1]. If one can get hold of the keytab(owned by YARN
user), I suppose at that point he can launch the container-executor binary too,
which will give him root access. So it's all predicated on secure setup to not
do stupid things.
bq. NMs currently share a global key container token secrets, but there is a
jira to move to per-NM secrets so sharing a global AM secret would be another
step backwards.
Agreed.
bq. Exploring alternate avenues to avoid global trust, is passing the allowed
am token allowed to get status and stop the container with the launch request
not feasible?
May be it isn't clear in my proposal, but let me state it again anyways, mostly
repeating what I just commented about on YARN-617.
- Having the authentication via container-token is forcing us to create a
connection per-container.
- MR's ContainerLauncher for example resorts to tricks like creating lots of
threads, opening and closing connections immediately to avoid hitting ulimits
etc.
- Most of that ugliness will go away if we perform all authentication using
AMTokens for *all* AM-NM APIs and use ContainerTokens for authorization of
startContainer() requests.
May be we should just do [1] above (previleged ports).
To sum it up, I am open to suggestions. My fundamental requirements are:
- If possible, AMs should open only one connection - secure one - to each NM.
Not one per container
- All connections (all APIs) between AM and NM should be authenticated -
DIGEST based at best here - and if possible without AMs having to latch on to
things like ContainerTokens for potentially long periods.
> 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: Vinod Kumar Vavilapalli
>
> 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
