Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Thu, 5 Feb 2015 07:27:35 +0000 (UTC)
From: "Jian He (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12770237.1422318898000.263659.1423121255800@Atlassian.JIRA>
In-Reply-To: <JIRA.12770237.1422318898000@Atlassian.JIRA>
References: <JIRA.12770237.1422318898000@Atlassian.JIRA>
 <JIRA.12770237.1422318898459@arcas>
Subject: [jira] [Commented] (YARN-3100) Make YARN authorization pluggable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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