Zhijie Shen updated YARN-1935:

    Attachment: Timeline_Kerberos_DT_ACLs.2.patch
                Timeline Security Diagram.pdf

Hi folks,

I've just attached a diagram "Timeline Security Diagram.pdf" to demonstrate the 
rough workflow of the the timeline security. In general, it consists of two 
parts: authentication and the authorization.

*1. Authentication*

a) When the authentication is enabled, a customized authentication filter will 
be loaded into the webapp of the timeline server, which prevents unauthorized 
users to access any timeline web resources. The filter allow users to:

* negotiate the authentication via HTTP SPNEGO, and login with Kerberos 
principal and keytab; and

* request a delegation token after Kerberos login and use it for follow-up 
secured communication.

b) TimelineClient is adapted to pass the authentication before putting the 
timeline data. It can choose append the Kerberos token or delegation token into 
the HTTP request. The rationale behind supporting delegation token is to allow 
AM and other containers to use TimelineClient to put the timeline data in a 
secured manner, where the Kerberos stuff is not available.

c) TimelineClient also has the API to get the delegation token from the 
timeline sever (actually from the customized authentication filter). When 
security is enabled and the timeline service is enabled, and YarnClient is used 
to submit an application, YarnClient will automatically call TimeClient to get 
a delegation token and put into the application submission context, such that 
the AM can used the passed-in delegation token to communicate with the timeline 
server securely.

d) Any tool which support SPNEGO/Kerberos, such as Firefox, curl and etc., can 
access the three GET APIs of the timeline server to inquiry the timeline data.

*2. Authorization*

Once the request from an authenticated user passes the customized 
authentication filter, it will be processed by the timeline web services. Here 
we use the ACLs manager to determine whether the user of the request has the 
access to the requested data. The basic rules are as follows:

* The access control granularity is entity, which means a user can access all 
the information of any entity and its events, or he/she can access nothing of 

* Currently we only allow the owner of the entity to access it. In the future, 
we can simply extend the rule to allow Admin and users/groups on the access 
control list.

After all, to enable the timeline security, we need to setup Kerberos. In 
addition, there're a bunch of configurations to do:

* Make use of the filter initializer to setup the customized authentication 
filter, and the configuration is much like hadoop-auth style; and

* ACLs is controlled by YARN ACLs configuration like other YARN daemons.

I also uploaded my newest uber patch "Timeline_Kerberos_DT_ACLs.2.patch" to 
demonstrate how the design is implemented

> Security for timeline server
> ----------------------------
>                 Key: YARN-1935
>                 URL: https://issues.apache.org/jira/browse/YARN-1935
>             Project: Hadoop YARN
>          Issue Type: New Feature
>            Reporter: Arun C Murthy
>            Assignee: Zhijie Shen
>         Attachments: Timeline Security Diagram.pdf, 
> Timeline_Kerberos_DT_ACLs.2.patch, Timeline_Kerberos_DT_ACLs.patch
> Jira to track work to secure the ATS

This message was sent by Atlassian JIRA

Reply via email to