We're updating the issue view to help you get more done. 

Creation of local datasets will fail on an impersonated namespace with non-default keytab url.

Description

If we have an impersonated namespace with a non-default keytab url, that is, keytab not under the value of security.keytab.path, then creation of the local datasets for workflow will fail with the following message:

This is happening since currently we are creating the local dataset with the principal from the ProgramOptions. When the principal is not null, cdap will try to look for the keytab file in the default path, which result in this error.

Creation on local datasets works fine if the namespace's keytab url is in the default path.

Release Notes

None

Activity

Show:
Terence Yim
June 10, 2017, 10:04 AM

It should never read the namespace key tab URI and it should not be readable at all even if the container attempts to do so.

Terence Yim
June 10, 2017, 10:07 AM

why it can read the key tab if it is in default location? Is it on HDFS? The permission should be readable by the "cdap" user only and the container should be launched with the impersonated user.

Yaojie Feng
June 12, 2017, 5:02 PM

The container is launched by the impersonated user but it is not this user who is actually reading the keytab file. The container will just provide the principal for the dataset creation, using the addInstance(..., ..., principal) method in DatasetFramework. This call will get to the DatasetInstanceService to create the dataset, which is done by the "cdap" user I think. Since the principal is provided, the DefaultUGIProvider will try to look for the keytab file in the default keytab path.

Yaojie Feng
June 27, 2017, 11:37 PM
Ali Anwar
October 13, 2017, 11:44 PM

On CDAP 4.2.0, seems like local datasets (even on a non-impersonated namespace) have the same failure affecting them.

Assignee

Yaojie Feng

Reporter

Yaojie Feng

Labels

None

Docs Impact

None

UX Impact

None

Components

Fix versions

Affects versions

Priority

Critical
Configure