| Table of Contents |
|---|
...
Hadoop's UserGroupInformation class has the following method:
// Log a user in from a keytab file.
UserGroupInformation loginUserFromKeytabAndReturnUGI(String user, String path);
...
Design of the necessary implementation for this has not been flushed out either, and will come later.
Problems Encountered
User applications writing to CDAP System tables
One of the aspects of impersonation that we did not consider is that YARN applications corresponding to a CDAP program will no longer have permissions as the 'cdap' system user. For instance, if the program is configured to be launched as user 'joe', it is not guaranteed that 'joe' has access to the 'cdap_system' hbase namespace or to system tables. However, the yarn application still (currently) writes to system tables.
Here are examples of when a user program writes to system tables:
- Update run records (started, stopped, etc).
- Updates to workflow token
- Lineage and usage registry updates upon calls to getDataset and addInput / addOutput
- Reading config store, for resolving runtime arguments, when launching programs from workflows
One possible solution to this is to still launch the YARN applications as the 'cdap' system user and only execute user code within it as the impersonated user (i.e. 'joe'). However, this does not doable because even when control is passed to the user, writes to system tables still can happen - for instance, when user calls getDataset or updateWorkflowToken.
An alternate solution is to expose a service in master (app-fabric?) that exposes functionality for specific writes to system tables. This would be a service that the user yarn application would call whenever it wants to record run record data, updates to workflow token, lineage, etc.
There are certainly downsides to this:
- Inefficiency - it would be more efficient for the client calling this service to directly make the writes/updates to hbase
- Potential bottleneck - if there are N workflows, each updating workflow token, this service would be a bottleneck for all of them
Any thoughts on this approach, or workable alternatives to this, are welcome.
Pending Questions
- How will admins configure multiple keytabs (for the various configured principals).
- Should we restrict updates to particular fields of the NamespaceConfig? Making it a 'final' configuration may simplify edge cases of the implementation, and will also reduce runtime failures. For instance, if user changes the principal of a namespace, the user would have to ensure that this new principal has all the appropriate permissions.
When launching jobs through twill, staging directory is always cdap/twill/...; Do we need to change twill to pass in staging dir through prepareRun?
- If a user is logged into cdap as 'ali', shouldn't we run the YARN app as user 'ali', instead of the mapping configured on the namespace/app/etc.?
- Programs launched by workflow - how will the appropriate principal be used for the launched programs (Mapreduce, Spark, Custom Action, etc).
...