hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-4348) Adding service-level authorization to Hadoop
Date Thu, 23 Oct 2008 20:00:44 GMT

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

Doug Cutting commented on HADOOP-4348:
--------------------------------------

Owen> if we put it just in the RPC layer, it is impossible to use any secure transport

That's an argument about authentication, not authorization, no?  Also, does Kerberos really
require a separate TCP connection per client, or rather does it require separate handshakes
and encryptions per client?  We could establish a separate session per client over a shared
connection...

A useful transport abstraction is reliable binary message exchange.  UDP is unreliable and
limits the message size, and TCP is stream-based.  We wish to exchange binary messages with
a server as efficiently as possible.  It will be simpler to focus on this problem if we can
keep it separate from others.  Handshakes, encryption, sessions, etc, can all be layered on
top of this abstraction, just as SSL and HTTP are layered on TCP.  Perhaps this abstraction
will prove impractical...

We need to agree on what features our transport layer provides.  Do we want the lowest level
to provide authenticated, authorized message exchange, or simply message channels, with authentication
and authorization layered above.  Or do we want to build on SSL-like standards (authenticated
byte streams) and layer per-user message exchange on that?  Even in the last case, authorization
can be layered above message exchange, and I think the lower we can push message exchange
the simpler things will be.  We don't want application authorization logic mixed in with async
i/o concerns if we can possibly avoid it.


> 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
>
>         Attachments: HADOOP-4348_0_20081022.patch, jaas_service_v1.patch
>
>
> 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.


Mime
View raw message