[
https://issues.apache.org/jira/browse/YARN-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15662027#comment-15662027
]
Varun Saxena edited comment on YARN-3053 at 11/14/16 10:42 AM:
---------------------------------------------------------------
[~sjlee0]
bq. How do other NMs (that are running the containers) authenticate? I don’t
think they can do a real authentication. Then how would they get the delegation
token for the app?
Authentication for NMs' will be similar to how authentication is currently done
for RM when it publishes entities to ATSv1. Each collector will load a
TimelineAuthenticationFilter just like timeline server in v1 was doing.
TimelineAuthenticationFilter will carry out kerberos and delegation token
authentication. This filter will negotiate auth via HTTP SPNEGO and then give a
delegation token which will be used for further communication. All the bits to
achieve this is in hadoop-common. Refer to
DelegationTokenAuthenticationHandler, for instance.
At the TimelineClient side, for ATSv1, we already have code to pass on kerberos
token or delegation token in HTTP request. Refer to
DelegationTokenAuthenticatedURL (in hadoop common) which is used in
TimelineClientImpl.
bq. How would each option handle the case of AM failures ?
This would be handled in the same way as timeline service address is passed.
When a new collector is launched, timeline service address will be reported
along with token by NM and based on rm ID and version we choose the applicable
timeline address. Token chosen will be based on the timeline address. Pls note
delegation tokens will also have to be stored in state store (depending on
where we generate the token) so that they are available again on recovery.
was (Author: varun_saxena):
[~sjlee0]
bq. How do other NMs (that are running the containers) authenticate? I don’t
think they can do a real authentication. Then how would they get the delegation
token for the app?
Authentication for NMs' will be similar to how authentication is currently done
for RM when it publishes entities to ATSv1. Each collector will load a
TimelineAuthenticationFilter just like timeline server in v1 was doing.
TimelineAuthenticationFilter will carry out kerberos and delegation token
authorization. This filter will negotiate auth via HTTP SPNEGO and then give a
delegation token which will be used for further communication. All the bits to
achieve this is in hadoop-common. Refer to
DelegationTokenAuthenticationHandler, for instance.
At the TimelineClient side, for ATSv1, we already have code to pass on kerberos
token or delegation token in HTTP request. Refer to
DelegationTokenAuthenticatedURL (in hadoop common) which is used in
TimelineClientImpl.
bq. How would each option handle the case of AM failures ?
This would be handled in the same way as timeline service address is passed.
When a new collector is launched, timeline service address will be reported
along with token by NM and based on rm ID and version we choose the applicable
timeline address. Token chosen will be based on the timeline address. Pls note
delegation tokens will also have to be stored in state store (depending on
where we generate the token) so that they are available again on recovery.
> [Security] Review and implement security in ATS v.2
> ---------------------------------------------------
>
> Key: YARN-3053
> URL: https://issues.apache.org/jira/browse/YARN-3053
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Reporter: Sangjin Lee
> Assignee: Varun Saxena
> Labels: YARN-5355
> Attachments: ATSv2Authentication(draft).pdf
>
>
> Per design in YARN-2928, we want to evaluate and review the system for
> security, and ensure proper security in the system.
> This includes proper authentication, token management, access control, and
> any other relevant security aspects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
