Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1970080430.1224489884462.JavaMail.jira@brutus>
Date: Mon, 20 Oct 2008 01:04:44 -0700 (PDT)
From: "Arun C Murthy (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-4348) Adding service-level authorization
 to Hadoop
In-Reply-To: <1560154647.1223237144145.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640943#action_12640943 ] 

Arun C Murthy commented on HADOOP-4348:
---------------------------------------

Here is a proposal for adding authorization to Hadoop:
 
 # The actual authorization mechanism is pluggable; by default it is config-based. In future we might add LDAP based authorization. The proposal is to add a new AuthorizationManager, along with a factory, which has 2 methods:
 #* {{void authorize(Class<?> protocol, UserGroupInformation ugi) throws AuthorizationException}}
 #* {{void reload()}} - Reload the config on the admin's command via a command-line option.
 # The default config-based authorization system has a new configuration file which lists ACL lists per-protocol, for e.g. this allows the admin to specify which user the DataNode should be running as, ditto for the TaskTracker. This configuration file is similar to the one specified by HADOOP-3698.
 # The authorization check should be made as early as possible i.e. when the Client connects to the Server over RPC. This ensures that the server isn't affected by mis-behaving/malicious clients e.g. DOS attacks.
 # Changes to the RPC system for authorization checking:
 #* Change the RPC Client to restrict it to only one protocol per connection, this ensures that we only need to do the authorization check once - on connection setup. This implies that the Client.ConnectionId to include the protocol, and it has to advertise the protocol on connection setup, in the header, along with the UGI. The Server uses the protocol and the UGI in the header for authorization.
 #* If the authorization fails, the Server immediately disconnects the Client's connection.
 #* Add a new AuthorizedProtocol interface which has one method: {{AuthorizationManager getAuthorizationManager()}} which returns the authorization system's implementation used by the RPC system on connection setup.
 # We assume that the AuthorizationManager implementation is spiffy-enough to inline the authorization on connection-setup from the client i.e. when the Server parses the {{ConnectionHeader}}.

Thoughts?


> Adding service-level authorization to Hadoop
> --------------------------------------------
>
>                 Key: HADOOP-4348
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4348
>             Project: Hadoop Core
>          Issue Type: New Feature
>            Reporter: Kan Zhang
>            Assignee: Arun C Murthy
>             Fix For: 0.20.0
>
>
> Service-level authorization is the initial checking done by a Hadoop service to find out if a connecting client is a pre-defined user of that service. If not, the connection or service request will be declined. This feature allows services to limit access to a clearly defined group of users. For example, service-level authorization allows "world-readable" files on a HDFS cluster to be readable only by the pre-defined users of that cluster, not by anyone who can connect to the cluster. It also allows a M/R cluster to define its group of users so that only those users can submit jobs to it.
> Here is an initial list of requirements I came up with.
>     1. Users of a cluster is defined by a flat list of usernames and groups. A client is a user of the cluster if and only if her username is listed in the flat list or one of her groups is explicitly listed in the flat list. Nested groups are not supported.
>     2. The flat list is stored in a conf file and pushed to every cluster node so that services can access them.
>     3. Services will monitor the modification of the conf file periodically (5 mins interval by default) and reload the list if needed.
>     4. Checking against the flat list is done as early as possible and before any other authorization checking. Both HDFS and M/R clusters will implement this feature.
>     5. This feature can be switched off and is off by default.
> I'm aware of interests in pulling user data from LDAP. For this JIRA, I suggest we implement it using a conf file. Additional data sources may be supported via new JIRA's.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.