Authorize a subset of operations on CDAP entities using Apache Sentry
Make the authorization system pluggable. Support the following two systems to begin with:
CDAP Dataset based
- User stories documented (Rohit/Bhooshan)
- User stories reviewed (Nitin)
- Design documented (Rohit/Bhooshan)
- Design reviewed (Andreas)
- Feature merged (Rohit/Bhooshan)
- Examples and guides (Rohit)
- Integration tests (Bhooshan)
- Documentation for feature (Rohit/Bhooshan)
- Blog post
- As a CDAP system, I should be able to integrate with Apache Sentry for fine-grained role-based access controls of select CDAP operations
- As a CDAP admin, I should be able to easily configure Sentry to work with CDAP on different type of cluster (ex: CDH, CM cluster etc).
- As a CDAP admin, I should be able to create/update/delete roles in Apache Sentry
- As a CDAP admin, I should be able to add users/groups to roles in Apache Sentry
- As a CDAP admin, I should be able to turn authorization on/off easily for entire CDAP instance
- As a CDAP system, I should be able to authorize the following requests
- Namespace create/update/delete
- Application deployment
- Program start/stop
- Stream read/write (Not Implemented in 3.4)
These operations are a subset that represents the various 'kinds' of operations allowed in CDAP
- D-Rock is an IT-Admin extra-ordinaire who has just been tasked with adding authorizing access to entities in CDAP on the cluster he manages.
- D-Rock is already familiar with Apache Sentry, since he has used it for authorization in other projects like Apache HDFS, Apache Hive, Apache Sqoop, etc.
- He would rather not learn a new authorization system. He would instead prefer that Apache Sentry be used to provide Role Based Access Control to CDAP entities as well.
- As part of this, he would also like a streamlined installation and configuration experience with Apache Sentry and CDAP, including detailed instructions.
- D-Rock manages a variety of CDAP clusters in dev/smoke/qa/staging environments along with the prod environment.
- For these environments, he would like to be able to turn authorization on/off easily with a switch for the CDAP instance, depending on the need at a given time.
- Ideally, D-Rock would like to be able to authorize all operations on all entities in CDAP.
- However, this can be rolled out in phases. In the initial phase, he would like to control who can:
- Create/update/delete a namespace
- Only users with WRITE permission on CDAP instance should be able to perform this operation.
- A property in
sentry-site.xmlwill decide a set of users who have admin permission on cdap instance. These admins can then later grant permissions to other users.
- Deploy an application in a namespace
- Only users with WRITE permission on the namespace should be able to perform this operation
- One the application is deployed the the user who deployed becomes the ADMIN of the application.
- Start/stop a program
- Only users with READ permission on the namespace and application, and EXECUTE permission on the program should be able to perform this operation
- Only users with ADMIN permission on the program can set preference for the program
- Only users with WRITE permission can provide runtime args
- Read/write to a stream
- Only users with READ privilege on the namespace and READ permission on the stream should be able to read from the stream
- Only users with READ privilege on the namespace and WRITE permission on the stream should be able to write to the stream
- Note: We have decided not to handle views separately. A user have same permission on all views of a stream as what it has on the stream.
- Create/update/delete a namespace
Entities, Operations and Privileges
|Entity||Operation||Required Privileges||Resultant Privileges|
|Namespace||create||ADMIN (Instance)||ADMIN (Namespace)|
|set preference||WRITE (Namespace)|
|get preference||READ (Namespace)|
|Artifact||add||WRITE (Namespace)||ADMIN (Artifact)|
|write property||ADMIN (Artifact)|
|delete property||ADMIN (Artifact)|
|get property||READ (Artifact)|
|write metadata||ADMIN (Artifact)|
|read metadata||READ (Artifact)|
|Application||deploy||WRITE (Namespace)||ADMIN (Application)|
|set preference||WRITE (Application)|
|get preference||READ (Application)|
|add metadata||ADMIN (Application)|
|get metadata||READ (Application)|
|set instances||ADMIN (Program)|
|set runtime args||EXECUTE (Program)|
|get runtime args||READ (Program)|
|get instances||READ (Program)|
|set preference||ADMIN (Program)|
|get preference||READ (Program)|
|get status||READ (Program)|
|get history||READ (Program)|
|add metadata||ADMIN (Program)|
|get metadata||READ (Program)|
|emit logs||WRITE (Program)|
|view logs||READ (Program)|
|emit metrics||WRITE (Program)|
|view metrics||READ (Program)|
|Streams||create||WRITE (Namespace)||ADMIN (Stream)|
|update properties||ADMIN (Stream)|
|read events||READ (Stream)|
|set preferences||ADMIN (Stream)|
|get preferences||READ (Stream)|
|add metadata||ADMIN (Stream)|
|get metadata||READ (Stream)|
|view lineage||READ (Stream)|
|emit metrics||WRITE (Stream)|
|view metrics||READ (Stream)|
|create||WRITE (Namespace)||ADMIN (Dataset)|
|executeAdmin (exists/truncate/upgrade)||ADMIN (Dataset)|
|add metadata||ADMIN (Dataset)|
|get metadata||READ (Dataset)|
|view lineage||READ (Dataset)|
|emit metrics||WRITE (Dataset)|
|view metrics||READ (Dataset)|
NOTE: Cells marked green are in scope for 3.4
This feature can be broken down into the following main parts, in no specific order:
Authorization in CDAP
The authorization system in CDAP will be pluggable, and the backend can be provided by external systems like Apache Sentry/Ranger. It provides:
- Authorization Enforcement hooks during various operations within CDAP, that throw
AuthorizationExceptionif the operation is not authorized.
- ACL Management
This system exposes a set of interfaces defined below.
AuthEnforcer interface provides a way to check if an operation is authorized. At various points in the CDAP code (NamespaceHttpHandler, AppLifecycleHttpHandler, ProgramLifecycleHttpHandler, StreamHandler in 3.4), this interface will be used to check if an operation is authorized.
This interface allows CDAP admins to grant/revoke permissions for specific operations on specific CDAP entities to specified Principals. It will be used by the ACL Management module, which may or may not reside in CDAP for the purposes of integration with Apache Sentry TBD.
Principal is the entity performing actions defined as below:
Integration with Apache Sentry will be achieved by implementations of these interfaces that delegate to Apache Sentry.
Integration with Apache Sentry
Integration with Apache Sentry involves the development of three main modules:
CDAP Sentry Binding
Here we will bind CDAP to SentryGenericServiceClient and to the operations on the client.
CDAP Sentry Model
The CDAP Sentry Model defines the CDAP entities for whom access needs to be authorized via Apache Sentry. It will based off of the Sentry Generic Authorization Model. The CDAP Sentry Model will have the following components:
This interface defines the CDAP entities that need to be authorized. It must implement Authorizable.
CDAPAuthorizable interface will have to be implemented for each authorizable entity defined by the
AuthorizableType enum above.
CDAPAction and CDAPActionFactory
TODO: Think about ALL, ADMIN_ALL
Sentry Policy Engine
Using the above authorizable model, resource URIs for CDAP entities in the Sentry Policy Engine will be as follows:
|Entity||Sentry Resource URI|
The above URIs are internal Apache Sentry representations defined at SentryAuthorizationModelDesign. They are only mentioned here to convey how the CDAP entity hierarchy will be represented in Apache Sentry.
Use-case: App Deployment by an unauthorized user
|List of users allowed to connect to the Sentry Server||cdap will be added to this list|
|Authorization provider for the CDAP component in Sentry. This class defines the user-group mapping amongst other things.|
|The resource for creating the Sentry Provider Backend. This property seems unused, and always defaults to "". However, all data engines (hive, sqoop, kafka define it).||""|
|A class that implements |
|Defines the Sentry Policy Engine for the cdap component. Must implement |
(package name subject to change)
These properties will be defined in
|Determines whether authorization should be enabled in CDAP. If false, a ||false|
|Fully qualified class name of the authorizer class. Must implement the |
|instance.name||Defines the instance name for the cdap component.||cdap|
To support RBAC (Role Based Access Control) such as Apache Sentry we will need to support role management through CDAP.
A user using RBAC should be able to:
- Create a role
- delete a role
- add role to principal (where principal can be of type user or group)
- remove role from a principal (where principal can be of type user or group)
- List roles
- List roles for principal
- List privileges for role
We will need to support this operation from through REST APIs and also through cli. Below is the proposed APIs and CLI commands:
There are multiple options for ACL Management. For dataset-based authorizer, we will have to support ACL Management via the CDAP CLI.
For Apache Sentry based authorizer, there are multiple options. We should support this via the CDAP CLI because it should involve very little extra work. However, support should also be provided via the SentryShell as well as Hue.
Although supporting the Sentry Shell seems straightforward once the CDAP backend for Sentry is implemented, it's a relatively new feature added in Sentry 1.7 (SENTRY-749). CDH 5.5 ships Sentry 1.5 and there are no timelines on support for Sentry 1.7 (Cloudera Maven Repository).
After some digging we found out that SentryShell is hardcoded to use work with Hive and it works only with Hive. At the moment of this writing, Kafka is added support for SentryShell by making a copy for Hive's SentryShell. This seems to be the norm in Sentry for Shell support since there is no generic Shell which can be used by the services being integrated to Sentry. Unless we have some strong reason we should avoid having support for CDAP through SentryShell, specially since we are already working on supporting ACL management for CDAP in Sentry through Hue. See below.
For recognizing and listing CDAP entities in Hue, we will have to implement a CDAP Webapp for Hue. Hue is implemented entirely in Python using the Django framework. This integration is a risk for 3.4. More details on this TBD.
For testing the sentry integration, there are a couple of approaches. We can use the file-based policy store in Apache Sentry for tests. However, to simulate more realistic scenarios, we should explore if it is easy to setup an in-memory database (HSQL, etc) with the Sentry schema in tests.
- How does CDAP get
sentry-site.xml? Path provided via
- Distinguishing Read/Write access is perhaps out of scope of 3.4, since we will need changes to Dataset Framework
- Can access to all entities be authorized in one go? If so, how?
- How does hierarchy work? e.g. write to stream requires READ perms on namespace + write perms on stream
- In a secure/kerberos environment, what does it take to communicate with the Sentry Server?
- In a secure/kerberos environment, what does it take to communicate with the Sentry Server?
- 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?
- What about instance-level authorization? Would users need to be authorized to a given CDAP instance as well, along with the namespace and entity?
- Do we need EXECUTE operation just for Programs entity. Can we say that any user who has READ can run the program ?
Discussion Bhooshan & Rohit 02/17
|CDAP Specific||External Auth Service: Sentry||ACL Management|
2. Authorization Checks
2. Figuring out how to interact with Sentry
|3. We need an Authorization interface|
Discussion with Gokul 02/08
- Push down ACLs - No HBase support in Sentry
- Custom datasets - how do you recognize read/writes
- How do you distinguish between read/write
- Sentry Integration - needs follow-ups
- Performance (num RPC calls)
- Sentry Persistent Storage - PolicyStoreProvider
- Interactions with Auth system
- Sentry web-app for UI may need customizations in Hue
- How does switching between authorization enabled/disabled work
Out-of-scope User Stories (3.5 and beyond)
- As a CDAP admin, I should be able to authorize reads/writes to datasets
- As a CDAP admin, I should be able to authorize metadata changes to CDAP entities
- As a CDAP system, I should be able to push down ACLs to storage providers
- As a CDAP admin, I should be able to authorize reads/writes to custom datasets
- As a CDAP system, I should be able to judge, document and improve the performance impact of authorization
- As a CDAP authorization system, I should be able to interact with an external authentication system
- As a CDAP admin, I should be able to use external UIs like Hue for ACL Management
- As a CDAP admin, I should be able to see an audit log of all authorization-related changes in CDAP
- As a CDAP admin, I should be able to authorize all thrift-based traffic, so transaction management is also authorized.