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

Jian He commented on YARN-3100:
-------------------------------


bq. Are these pluggable types? Are there other, future entities besides queues? 
Should the authorizer plugin perform the mapping from QueueACL? 
PrivilegedEntity - we'll add ApplicationACL, TimeLineACL into the EntityType 
later on. Similar for AccessType - we'll add VIEW_APP, MODIFY_APP etc. later 
on. The plugin will decide for each entity(app/queue) whether a certain user 
has the permission to perform certain operation. 
bq.  While it's a noop for external services, aren't these different semantics 
from the current implementation?
The assumption is that if user chooses to use the external component for acl 
management, user should be aware to rely on that for grant/revoke acls.  
Otherwise, e.g. if user adds a bunch permissions in Ranger but then later on 
admin invoke refreshQueue CLI just to add a new queue(not to change the acl), 
it'll override what Ranger has which I think is not expected. Alternatively, 
the plug-in can choose to add new acl via the setPermission when refreshQueue 
is invoked, but not to replace existing acl.
bq. Readers are blocked, so there are no locks necessary for modifications by 
setPermission
I'm not sure if I get your point, the DefaultYarnAuthorizer currently uses a 
concurrentHashMap to store the acls, setPermission is currently used on queue 
initialization. So I think lock on setPermission is not needed ?


> Make YARN authorization pluggable
> ---------------------------------
>
>                 Key: YARN-3100
>                 URL: https://issues.apache.org/jira/browse/YARN-3100
>             Project: Hadoop YARN
>          Issue Type: Bug
>            Reporter: Jian He
>            Assignee: Jian He
>         Attachments: YARN-3100.1.patch, YARN-3100.2.patch
>
>
> The goal is to have YARN acl model pluggable so as to integrate other 
> authorization tool such as Apache Ranger, Sentry.
> Currently, we have 
> - admin ACL
> - queue ACL
> - application ACL
> - time line domain ACL
> - service ACL
> The proposal is to create a YarnAuthorizationProvider interface. Current 
> implementation will be the default implementation. Ranger or Sentry plug-in 
> can implement  this interface.
> Benefit:
> -  Unify the code base. With the default implementation, we can get rid of 
> each specific ACL manager such as AdminAclManager, ApplicationACLsManager, 
> QueueAclsManager etc.
> - Enable Ranger, Sentry to do authorization for YARN. 



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

Reply via email to