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 23:43:11 GMT
>
>
>
>
> On 3/25/09 12:12 PM, "Amandeep Khurana" <amansk@gmail.com> wrote:
>
> >>
> >>
> >> On 3/20/09 2:47 PM, "Amandeep Khurana" <amansk@gmail.com> 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.
> >>>
> >>
> >> Have you looked at HADOOP-4359? In that JIRA, we discussed the idea of
> >> using
> >> public-key signed capabilities and dismissed it in favor of
> symmetric-key
> >> based capabilities. That said, you're welcome to explore the public-key
> >> idea
> >> further.
> >
> >
> > Yes, I read through that. The issue with that approach is that the moment
> a
> > single DN gets compromised somehow (which isnt a big deal in a big system
> > containing 1000s of nodes), the symmetric key gets exposed and the entire
> > system is compromised. The whole idea of asymmetric key crypto is to
> allow
> > only a single authorized prinicipal to sign stuff.
> >
> Yes, I discussed this point in the JIRA. It's a trade-off between security
> and performance and I think it's worth taking for our cluster setup. In our
> setup, all the nodes of a cluster are located in the same datacenter and
> managed in the same way. While securing 1000 nodes is certain harder than
> securing one node, it's not like you have 1000 desktops spread around.
> You're welcome to submit a patch for the public-key solution. It can be
> useful for some other cluster setups.
>

Makes sense... Performance definitely is a concern but if you look at the
results that I got out of the basic testing I did, its really not big.


>
> Kan
>
>

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