Hi Everyone,
I wanted to get some of by RBAC enhancement thoughts down on paper.

The key concept is really the notions of a Knox roles and privileges. A role is typically (partially) defined as a collection of privileges so lets start there. For this discussion I will define a privilege as the combination of a "service role" (e.g. WEBHDFS) and HTTP verbs (e.g. GET, PUT, POST, DELETE, etc.). So example privileges might be:

WEBHDFS: GET
OOZIE: GET,POST
HIVE: GET

Roles then are a named combination of privileges.  Some examples:

data-admin
    WEBHDFS:GET,PUT,POST,DELETE
data-scientist
    WEBHDFS:GET
    OOZIE: GET,POST
    HIVE: GET

Then Knox should be able to map groups obtained at authentication time (e.g. LDAP) to one or more of these roles.
This does lead to the natural questions:
1) How is the group->role mapping managed?
2) There needs to be a simple way to have the have the roles come directly from LDAP such that mapping at the Knox level isn't required

Seeing this on paper does raise in issue for me that might make the HTTP verb part a problem. A "data-scientist" should probably always have HDFS GET,PUT,POST,DELETE for /user/{uid} directory but the point of the role may be to prevent file deletion. But I don't think Knox should be in the resource authorization business. So perhaps a role is just a collection of services (i.e. without verb control) or would that just be optional and rarely used?

Kevin.

--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.

Reply via email to