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 Thu, 26 Mar 2009 03:30:54 GMT
On Wed, Mar 25, 2009 at 1:43 PM, Kan Zhang <kan@yahoo-inc.com> wrote:

>
>
>
> On 3/25/09 1:04 PM, "Kan Zhang" <kan@yahoo-inc.com> wrote:
>
> >
> >
> >
> > On 3/25/09 12:15 PM, "Amandeep Khurana" <amansk@gmail.com> wrote:
> >
> >> On Wed, Mar 25, 2009 at 2:49 AM, Doug Cutting <cutting@apache.org>
> wrote:
> >>
> >>> Amandeep Khurana wrote:
> >>>
> >>>> 1. The Jira covers only authentication using Kerberos. I dont think
> >>>> Kerberos
> >>>> is the best way to do it since I feel the scalability is limited. All
> keys
> >>>> have to be negotiated by the Kerberos server.
> >>>>
> >>>
> >>> The design in HADOOP-4343 seeks to minimize the number of key
> negotiations.
> >>>  Do you think that's insufficient?  If so, please add a comment on that
> >>> issue.
> >>
> >>
> >> The NN doing key negotiations is fundamentally not feasible. Thats the
> >> limitation of Kerberos and there's only a certain degree to which it can
> be
> >> optimized. The design I proposed in the paper is a little different from
> >> Kerberos, where the clients negotiate the keys. This frees up the NN
> from
> >> the responsibility to do this task.
> >>
> > You've lost me. What are you referring to when you say key negotiations?
> As
> > far as I read from your paper, you didn't propose anything new for the
> > authentication between NN and the user, simply mentioning it will be a
> > Kerberos like protocol. If you are referring to those capabilities for
> > accessing DN, those are issued by NN, right?
> >
> My bad. I read your doc again and I guess you are referring to the protocol
> you proposed in the paper for the authentication to datanode using namenode
> as a trusted third-party. But the namenode is certainly involved in the
> issuing of the ticket, right? Whereas if you use Kerberos, that task can be
> off-loaded to the Kerberos KDC.


The NN issues a ticket to a client once and the client goes ahead and
negotiates the keys. So, we dont need a Kerberos KDC and no other principal
in the system is loaded... At the same time, the NN has full control over
who gets into the system.

>
>
> Kan
>
>

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