hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jian He (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (YARN-3100) Make YARN authorization pluggable
Date Thu, 05 Feb 2015 07:32:35 GMT

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

Jian He edited comment on YARN-3100 at 2/5/15 7:32 AM:
-------------------------------------------------------

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 Application, TimeLineDomain etc. 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 ?



was (Author: jianhe):

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)

Mime
View raw message