Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

ACL management (either using CDAP CLI or via external systems like Sentry CLI or Hue)

Design Scribble:

To integrate with CDAP we will need implementation of the following modules.

Main modules:

  • Binding: Authorization checks happen here

  • Model: Define what are the objects in your system that you want to control access and define the granularity

  • Policy engine: Define how you want to evaluate policies. For example: Wildcards?

Model:

 

Action:
Sentry has an interface which defines an Action:
We can use abstract class BitFieldAction and define action for CDAP entities. Since, we need different action for different entities we will have to define them separately:

 

Binding:

Policy:

//TODO

 

 

Note: Will have to whitelist the cdap user for the Sentry Service.

ACL management

  • TBD: either using CDAP CLI or via external systems like Sentry CLI or Hue (question)

Questions

  1. How does CDAP get sentry-site.xml? Path provided via cConf?
  2. Distinguishing Read/Write access is perhaps out of scope of 3.4, since we will need changes to Dataset Framework
  3. Can access to all entities be authorized in one go? If so, how? 
  4. How does hierarchy work? e.g. write to stream requires READ perms on namespace + write perms on stream
  5. In a secure/kerberos environment, what does it take to communicate with the Sentry Server?
  6. In a secure/kerberos environment, what does it take to communicate with the Sentry Server?
  7. Given that Sentry has a slightly data-engine-based schema, will we need some updates to the policy store to contain CDAP specific tables for storing CDAP Privileges? SENTRY_CDAP_PRIVILEGE and SENTRY_CDAP_PRIVILEGE_MAP tables?
  8. What about instance-level authorization? Would users need to be authorized to a given CDAP instance as well, along with the namespace and entity?

...