[
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)
