[
https://issues.apache.org/jira/browse/YARN-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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
it.
* 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.
*Configuration*
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
(v6.2#6252)
