hadoop-common-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Dunning" <ted.dunn...@gmail.com>
Subject Re: compressed/encrypted file
Date Thu, 05 Jun 2008 23:37:47 GMT
Yes, that is what I meant.

Not particularly good, but possibly the best we can do with hadoop (for a
while).  If hadoop handles the ticket for us in a secure way, then I would
feel better.

On Thu, Jun 5, 2008 at 3:40 PM, Haijun Cao <haijun@kindsight.net> wrote:

>
>
> "If and when something like kerberos user authentication exists, then
> kerberos
> tickets may be the reasonable alternative for opening the keyring."
>
> Ted,
>
> Do you mean instead of "insert an auth key to the job conf", we can insert
> the ticket to the job conf? even though the job conf itself can be
> compromised, since the ticket is short lived, other people can't use the
> ticket to decrypt the file later. Is my understanding right?
>
>
>
> Thanks
> Haijun
>
> -----Original Message-----
> From: Ted Dunning [mailto:ted.dunning@gmail.com]
> Sent: Thursday, June 05, 2008 11:58 AM
> To: core-user@hadoop.apache.org
> Subject: Re: compressed/encrypted file
>
> Security and hadoop are not particularly compatible concepts.  Things may
> improve when user authentication exists.  The lack of security on job confs
> is the major motivation for making sure the auth is time limited.  If and
> when something like kerberos user authentication exists, then kerberos
> tickets may be the reasonable alternative for opening the keyring.
>
> Can you suggest an alternative way to communicate a secret to hadoop tasks
> short of embedding it into source code?
>
> On Thu, Jun 5, 2008 at 11:46 AM, Allen Wittenauer <aw@yahoo-inc.com>
> wrote:
>
> > On 6/5/08 11:38 AM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
> > > We use encryption on log files using standard AES.  I wrote an input
> > format
> > > to deal with it.
> > >
> > > Key distribution should be done better than we do it.  My preference
> > would
> > > be to insert an auth key into the job conf which is then used by the
> > input
> > > to open a well known keyring via an API that prevents auths from
> > surviving
> > > for long term.
> >
> >    This sounds like it opens the door for key stealing in a
> > multi-user/static job tracker system, since the job conf is readable by
> all
> > jobs running on the same machine.
> >
> >
>
>
> --
> ted
>



-- 
ted

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