hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bc Wong (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-941) RM Should have a way to update the tokens it has for a running application
Date Tue, 20 May 2014 15:28:38 GMT

    [ https://issues.apache.org/jira/browse/YARN-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003440#comment-14003440

bc Wong commented on YARN-941:

Hi [~xgong], thanks for the patch! I'm interested in talking through the changes and their
security implications, for everybody who's following along. I think the following are worth

# The token update mechanism is via the AM heartbeat. So if the previous AMRM token has been
compromised, the attacker can get the new token.
** I don't think it's a big problem as the RM will only hand out the new token in _exactly_
one AllocateResponse (except for the case of RM restart). So if the attacker has the new token,
the real AM won't, and it'll die and the token will get revoked.
# How frequently a running AM gets an updated token is at the mercy of the configuration (the
roll interval and activation delay). In addition, whenever the RM restarts, all AMs will get
a new token on the next heartbeat.
** Should the RM check that the roll interval and activation delay are both shorter than the
token expiration interval?
# The client app is not responsible for renewing the token. The RM will renew it proactively
and update the apps.
** The loss of control may be inconvenient to the app. The AM must also heartbeat frequently
enough to catch the update in time. In practice, it's not an issue. But it still makes me
slightly uncomfortable, since the client is the usually one renewing its credentials, of all
other security protocols I know of. Here, the RM doesn't have any explicit logic to update
an AMRM token before it expires. The math just generally works out if the admin sets the token
expiry, roll interval and activation delay to the right values.\\
Again, I think this is better than making it the AM's responsibility to get a new token, which
is more burden on the AM. I just want to bring this up for discussion.

> RM Should have a way to update the tokens it has for a running application
> --------------------------------------------------------------------------
>                 Key: YARN-941
>                 URL: https://issues.apache.org/jira/browse/YARN-941
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Robert Joseph Evans
>            Assignee: Xuan Gong
>         Attachments: YARN-941.preview.2.patch, YARN-941.preview.3.patch, YARN-941.preview.patch
> When an application is submitted to the RM it includes with it a set of tokens that the
RM will renew on behalf of the application, that will be passed to the AM when the application
is launched, and will be used when launching the application to access HDFS to download files
on behalf of the application.
> For long lived applications/services these tokens can expire, and then the tokens that
the AM has will be invalid, and the tokens that the RM had will also not work to launch a
new AM.
> We need to provide an API that will allow the RM to replace the current tokens for this
application with a new set.  To avoid any real race issues, I think this API should be something
that the AM calls, so that the client can connect to the AM with a new set of tokens it got
using kerberos, then the AM can inform the RM of the new set of tokens and quickly update
its tokens internally to use these new ones.

This message was sent by Atlassian JIRA

View raw message