hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Design for security in Hadoop
Date Mon, 30 Mar 2009 15:39:39 GMT
Amandeep Khurana wrote:
> On Wed, Mar 25, 2009 at 12:23 PM, Kan Zhang <kan@yahoo-inc.com> wrote:
>> On 3/25/09 2:49 AM, "Doug Cutting" <cutting@apache.org> wrote:
>>>> 2. The Jira doesnt have cover the access control aspect of things. As a
>>>> client, I can skip talking to the NN and get blocks from the DN straight
>>>> away. There is no way to prevent it. This paper takes care of that
>> aspect as
>>>> well.
>>> The intent is that access to a block on a datanode will require
>>> authentication.  Currently it does not, but as security features are
>>> added this clearly must change.  HADOOP-4343 does not mention how this
>>> will be done, but I believe it must be implemented in the same timeframe
>>> as namenode authentication.
>> We plan to use capability tokens issued by NN to control accesses to DN
>> (see
>> HADOOP-4359). If DN authenticates users, those capability tokens can be
>> made
>> non-transferable. This will improve security since stolen tokens can't be
>> used by the attacker. Another benefit of having authentication is to be
>> able
>> to establish an encrypted communication channel afterwards (if the
>> authentication protocol used supports it). However, I think DN user
>> authentication may not be necessary for many use cases and can be addressed
>> after NN authentication is done.
> Got it. There is no user authentication at the DN. I'm not sure why you got
> that impression. Authentication is done only once by the NN. Thereafter its
> only capabilities being passed around. However, there are 2 main
> differences:
> 1. You plan to use symmetric key and I proposed asymmetric key.
> 2. The authentation protocol you plan to use is Kerberos and I dont think
> thats scalable. Hence a different one that my paper talks about.

Brian's points about x509 integration are relevant -they are people who 
have to worry about trust.

There's a separate issue bubbling up here and that is US government 
export rules regarding encryption and the like. Apache has to deal with 
that already, and has a page covering the status:

generally, if you use jsch or the bouncy castle implementations of JSSE 
then it's not your project's problem. Building security and encryption 
support more directly into the app is something that needs to be looked 
at very carefully.  It's where legal issues take priority over coding ones.

View raw message