apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "devendra tagare (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (APEXCORE-636) Ability to refresh tokens using user's own kerberos credentials in a managed environment where the application is launched using an admin with impersonation
Date Sat, 04 Feb 2017 01:54:51 GMT

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

devendra tagare commented on APEXCORE-636:


In the current kerberos implementation, the credentials of the system user need to be passed
at launch.
This can be done by passing the principal (-kp) and keytab (-kt) as optional arguments at

For delegation token renewal, the kerberos keytab path in HDFS is specified using dt.authentication.store.keytab
This path needs to be shared among all users to work in a multi-tenant env with impersonation
since the impersonators credentials are used at launch.

For delegation token refresh, the principal picked up is the principal of the StramUserLogin
(System user/Impersonator).

Given this passing the individual user's keytab using -Ddt.authentication.store.keytab=<individual
user keytab path> will not work since the principal being picked would be of the SystemUser,

To give the individual users the ability to launch applications with their credentials we
can add a property to StramClientUtils - dt.authentication.token.refresh.principal to pass
the user principal of the individual user along with the user's keytab at launch from apex

The launch command would look something like below,

 HADOOP_USER_NAME=<individualUser> apex -kp impersonator@realm -kt path_to_keytab_file
-e "launch -Ddt.authentication.store.keytab=<path_to_individualUser_keytab> -Ddt.authentication.token.refresh.principal=individualUser@realm.com
appPackage.apa appName -exactMatch " -vvvv

In case impersonation is not enabled and an individual user want's to run under his own account
the semantics will continue to work as is by configuring dt.authentication.principal,dt.authentication.keytab
and dt.authentication.store.keytab properties under the $USER_HOME/.dt/dt-site.xml.


> Ability to refresh tokens using user's own kerberos credentials in a managed environment
where the application is launched using an admin with impersonation
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: APEXCORE-636
>                 URL: https://issues.apache.org/jira/browse/APEXCORE-636
>             Project: Apache Apex Core
>          Issue Type: Bug
>            Reporter: Pramod Immaneni
>            Assignee: devendra tagare
> When applications run in secure mode, they use delegation tokens to access Hadoop resources.
These delegation tokens have a lifetime, typically 7 days, after which they no longer work
and the application will not be able to communicate with Hadoop. Apex can automatically refresh
these tokens before they expire. To do this it requires Kerberos credentials which should
be supplied during launch time.
> In a managed environment the user launching the application may not be intended runtime
user for the application. Apex today supports impersonation to achieve this. Typically, a
management application uses its own credentials, which typically have higher privilege, to
launch the application and impersonate as a regular user so that the application runs as the
regular user. However, the admin credentials are also packaged with the application to for
refreshing the tokens described above. This can cause a security concern because a regular
user has access to a higher privilege Kerberos credentials.
> We need a way to specify alternate kerberos credentials to be used for token refresh.
Today there is a partially implemented feature for this which allows specification of the
refresh keytab using a property but not the principal. We would need to add support for the
principal as well.

This message was sent by Atlassian JIRA

View raw message