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.


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



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.


Yaojie Feng


Yaojie Feng



Docs Impact


UX Impact



Fix versions

Affects versions