[ 
https://issues.apache.org/jira/browse/AMBARI-11350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002700#comment-15002700
 ] 

Robert Levas commented on AMBARI-11350:
---------------------------------------

[~jaoki]...

Thanks!

Currently we have no plans for such a role, however the architecture lends 
itself to allow such a role to be created in the future.  Essentially we would 
need to come up with a set of "authorizations" (or permissions) that fill the 
gap and create a new role that encapsulates them.  Minimal changes to the back- 
and front-ends will need to be made to enforce rules for any new 
_authorizations_. However if the difference is only a new role with a subset of 
the existing authorizations, when not changes are needed other than a few 
records in the database.  

The architecture lends itself to creating new roles dynamically, so in the 
future we can enhance the UI and API to allow for this. Current the API exposes 
read-only access to the relevant resources, but the change wouldn't be 
difficult to add create and modify endpoints. 

Thanks for your input. 

> Finer-grained role AuthZ for Ambari Users
> -----------------------------------------
>
>                 Key: AMBARI-11350
>                 URL: https://issues.apache.org/jira/browse/AMBARI-11350
>             Project: Ambari
>          Issue Type: Epic
>          Components: ambari-server
>    Affects Versions: 2.0.0
>            Reporter: Jeff Sposetti
>            Assignee: Robert Levas
>              Labels: permissions, rbac, roles
>         Attachments: AmbariRole-basedAccessControl.pdf
>
>
> Ambari currently integrates with external authentication systems and is able 
> to authenticate users using enterprise-wide LDAP systems, such as Active 
> Directory, OpenLDAP, and Apache Directory Service. However, more flexibility 
> is now needed to allow for those authenticated users to be segmented into 
> more granular roles.  These roles allow Ambari-level administrators to create 
> different levels of cluster-level administrators to manage certain 
> administrative operations that need to be performed on a cluster. This 
> effectively spreads out the responsibilities of managing a cluster while not 
> handing over total control of the Ambari management facility. 
> Ambari to provide role-based access controls beyond today's Ambari Admin, 
> Operator and Read-Only permissions.
> || Role || Description ||
> | *Cluster User* (was Read-only) | This exists as of Ambari 1.7.0. Read-only 
> view of cluster information, including configurations, service status and 
> health alerts|
> | *Service Operator* | Provides control of service lifecycle 
> (start/stop/restart/decomm/recom) |
> | *Service Administrator* | Service Operator + ability to re-configure 
> (change/compare/revert), configure HA |
> | *Cluster Operator* | Service Administrator + add/remove hosts and 
> components (for existing services) |
> | *Cluster Administrator* | Cluster Operator + enable/disable kerberos, 
> modify alerts, add service, perform upgrade (renamed from Operator) |
> | Administrator | This exists as of Ambari 1.7.0. Full cluster control + 
> manage user, groups and views and this flag is applicable to any user 
> regardless of Role |
> Each role is to have permissions as shown below:
> || || Cluster\\User || Service\\Operator || Service\\Administrator || 
> Cluster\\Operator || Cluster\\Administrator || Administrator ||
> ||Service-level Permissions||
> |View metrics                  |(+)|(+)|(+)|(+)|(+)|(+)|
> |View status information       |(+)|(+)|(+)|(+)|(+)|(+)|
> |View configurations           |(+)|(+)|(+)|(+)|(+)|(+)|
> |Compare configurations        |(+)|(+)|(+)|(+)|(+)|(+)|
> |View alerts        |(+)|(+)|(+)|(+)|(+)|(+)|
> |Start/Stop/Restart Service    |   |(+)|(+)|(+)|(+)|(+)|
> |Decommission/recommission     |   |(+)|(+)|(+)|(+)|(+)|
> |Run service checks            |   |(+)|(+)|(+)|(+)|(+)|
> |Turn on/off maintenance mode  |   |(+)|(+)|(+)|(+)|(+)|
> |Perform service-specific tasks|   |(+)|(+)|(+)|(+)|(+)|
> |Modify configurations         |   |   |(+)|(+)|(+)|(+)|
> |Manage configuration groups   |   |   |(+)|(+)|(+)|(+)|
> |Move to another host          |   |   |(+)|(+)|(+)|(+)|
> |Enable/disable alerts          |   |   |(+)|(+)|(+)|(+)|
> |Enable HA                     |   |   |(+)|(+)|(+)|(+)|
> |Add Service to cluster        |   |   |   |   |(+)|(+)|
> ||*Host-level Permissions*||
> |View metrics                  |(+)|(+)|(+)|(+)|(+)|(+)|
> |View status information       |(+)|(+)|(+)|(+)|(+)|(+)|
> |View configuration            |(+)|(+)|(+)|(+)|(+)|(+)|
> |Turn on/off maintenance mode  |   |   |   |(+)|(+)|(+)|
> |Install components            |   |   |   |(+)|(+)|(+)|
> |Add/Delete hosts              |   |   |   |(+)|(+)|(+)|
> ||Cluster-level Permissions||
> |View metrics                  |(+)|(+)|(+)|(+)|(+)|(+)|
> |View status information       |(+)|(+)|(+)|(+)|(+)|(+)|
> |View configuration            |(+)|(+)|(+)|(+)|(+)|(+)|
> |View stack version details    |(+)|(+)|(+)|(+)|(+)|(+)|
> |View alerts                   |(+)|(+)|(+)|(+)|(+)|(+)|
> |Enable/disable alerts         |   |   |   |   |(+)|(+)|
> |Enable/disable Kerberos       |   |   |   |   |(+)|(+)|
> |Upgrade/downgrade stack       |   |   |   |   |(+)|(+)|
> ||Ambari-level Permissions||
> |Create new clusters           |   |   |   |   |   |(+)|
> |Set service users and groups  |   |   |   |   |   |(+)|
> |Rename clusters               |   |   |   |   |   |(+)|
> |Manage users                  |   |   |   |   |   |(+)|
> |Manage groups                 |   |   |   |   |   |(+)|
> |Manage Ambari Views           |   |   |   |   |   |(+)|
> |Assign permissions/roles      |   |   |   |   |   |(+)|
> |Manage stack versions         |   |   |   |   |   |(+)|
> |Edit stack repository URLs    |   |   |   |   |   |(+)|



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to