hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amandeep Khurana <ama...@gmail.com>
Subject Re: Design for security in Hadoop
Date Wed, 25 Mar 2009 20:17:38 GMT
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.





>
>
> Kan
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message