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.
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.
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.
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