Encryption

[Lars George <la...@gmail.com>]

Hey,

I was wondering if along with the DAC or before you ever considered
encrypting data? Like the compression, have a ColFam parameter that
specifies the encryption and the required details (password or
certificate/key) and it transparently encrypts the data written to DFS. We
did talk about this during the Munich OpenHUG and I was curious to know if
there was ever something like this considered.

Lars

Re: Encryption

[Lars George <la...@gmail.com>]

Hi Andy,

I think this was more for native-Java to API. As that is RPC and not
secure, right? But I think I am good with what we talked about. If
someone really wants to secure their data then they have to do this
outside of HBase and be done with it. Wire security is only a minor
part in the overall scheme of things. Thanks!

Lars

On Fri, Dec 18, 2009 at 6:49 PM, Andrew Purtell <ap...@apache.org> wrote:
> In other words, HTTPS to a REST connector. With transactions over persistent
> HTTPS connections, that's hardly crazy. This is done all the time. That kind
> of natural layering -- in this case, authentication and encryption services on
> top of data access -- is to a large degree what REST is all about. Incidentally
> Stargate, as a servlet, can take advantage of the SSL transport and client
> and server certificate management support of its container, so we support this
> right now.
>
> But, like with just punting to the client to encrypt (or not), in both cases
> we are talking about application specific system engineering outside the scope
> of HBase proper. Regarding that, I personally don't have any objection to
> putting some support for data encryption directly in, but I don't see a real
> need for it either.
>
>   - Andy
>
>
>
> ----- Original Message ----
>> From: Lars George <la...@gmail.com>
>> To: hbase-dev@hadoop.apache.org
>> Sent: Fri, December 18, 2009 2:52:12 AM
>> Subject: Re: Encryption
>>
>> No immediate need, just wondered if that makes sense at all or is already
>> thought of. I guess the idea is that data cannot be read from the storage
>> directly. But then it is still unprotected on its way from the client to the
>> RS's - and adding SSL to RPC seems "crazy". I guess best is to let the
>> client encrypt the values before even hitting the API?
>>
>> On Fri, Dec 18, 2009 at 2:10 AM, Andrew Purtell wrote:
>>
>> > There hasn't been an issue filed for it. I just checked.
>> >
>> > What's the problem being solved?
>> >
>> > Architecturally I'd consider encryption at the HBase/storage infrastructure
>> > perimeter, layered on top of a RESTful service. SSL.
>> >
>> >   - Andy
>> >
>> >
>> >
>> > ----- Original Message ----
>> > > From: Lars George
>> > > To: hbase-dev@hadoop.apache.org
>> > > Sent: Thu, December 17, 2009 4:35:51 PM
>> > > Subject: Encryption
>> > >
>> > > Hey,
>> > >
>> > > I was wondering if along with the DAC or before you ever considered
>> > > encrypting data? Like the compression, have a ColFam parameter that
>> > > specifies the encryption and the required details (password or
>> > > certificate/key) and it transparently encrypts the data written to DFS.
>> > We
>> > > did talk about this during the Munich OpenHUG and I was curious to know
>> > if
>> > > there was ever something like this considered.
>> > >
>> > > Lars
>> >
>> >
>> >
>> >
>> >
>> >
>
>
>
>
>
>

Re: Encryption

[Andrew Purtell <ap...@apache.org>]

In other words, HTTPS to a REST connector. With transactions over persistent
HTTPS connections, that's hardly crazy. This is done all the time. That kind
of natural layering -- in this case, authentication and encryption services on
top of data access -- is to a large degree what REST is all about. Incidentally
Stargate, as a servlet, can take advantage of the SSL transport and client
and server certificate management support of its container, so we support this
right now. 

But, like with just punting to the client to encrypt (or not), in both cases
we are talking about application specific system engineering outside the scope
of HBase proper. Regarding that, I personally don't have any objection to
putting some support for data encryption directly in, but I don't see a real
need for it either. 

   - Andy



----- Original Message ----
> From: Lars George <la...@gmail.com>
> To: hbase-dev@hadoop.apache.org
> Sent: Fri, December 18, 2009 2:52:12 AM
> Subject: Re: Encryption
> 
> No immediate need, just wondered if that makes sense at all or is already
> thought of. I guess the idea is that data cannot be read from the storage
> directly. But then it is still unprotected on its way from the client to the
> RS's - and adding SSL to RPC seems "crazy". I guess best is to let the
> client encrypt the values before even hitting the API?
> 
> On Fri, Dec 18, 2009 at 2:10 AM, Andrew Purtell wrote:
> 
> > There hasn't been an issue filed for it. I just checked.
> >
> > What's the problem being solved?
> >
> > Architecturally I'd consider encryption at the HBase/storage infrastructure
> > perimeter, layered on top of a RESTful service. SSL.
> >
> >   - Andy
> >
> >
> >
> > ----- Original Message ----
> > > From: Lars George 
> > > To: hbase-dev@hadoop.apache.org
> > > Sent: Thu, December 17, 2009 4:35:51 PM
> > > Subject: Encryption
> > >
> > > Hey,
> > >
> > > I was wondering if along with the DAC or before you ever considered
> > > encrypting data? Like the compression, have a ColFam parameter that
> > > specifies the encryption and the required details (password or
> > > certificate/key) and it transparently encrypts the data written to DFS.
> > We
> > > did talk about this during the Munich OpenHUG and I was curious to know
> > if
> > > there was ever something like this considered.
> > >
> > > Lars
> >
> >
> >
> >
> >
> >



      

Re: Encryption

[Lars George <la...@gmail.com>]

No immediate need, just wondered if that makes sense at all or is already
thought of. I guess the idea is that data cannot be read from the storage
directly. But then it is still unprotected on its way from the client to the
RS's - and adding SSL to RPC seems "crazy". I guess best is to let the
client encrypt the values before even hitting the API?

On Fri, Dec 18, 2009 at 2:10 AM, Andrew Purtell <ap...@apache.org> wrote:

> There hasn't been an issue filed for it. I just checked.
>
> What's the problem being solved?
>
> Architecturally I'd consider encryption at the HBase/storage infrastructure
> perimeter, layered on top of a RESTful service. SSL.
>
>   - Andy
>
>
>
> ----- Original Message ----
> > From: Lars George <la...@gmail.com>
> > To: hbase-dev@hadoop.apache.org
> > Sent: Thu, December 17, 2009 4:35:51 PM
> > Subject: Encryption
> >
> > Hey,
> >
> > I was wondering if along with the DAC or before you ever considered
> > encrypting data? Like the compression, have a ColFam parameter that
> > specifies the encryption and the required details (password or
> > certificate/key) and it transparently encrypts the data written to DFS.
> We
> > did talk about this during the Munich OpenHUG and I was curious to know
> if
> > there was ever something like this considered.
> >
> > Lars
>
>
>
>
>
>

Re: Encryption

[Andrew Purtell <ap...@apache.org>]

There hasn't been an issue filed for it. I just checked. 

What's the problem being solved?

Architecturally I'd consider encryption at the HBase/storage infrastructure
perimeter, layered on top of a RESTful service. SSL. 

   - Andy



----- Original Message ----
> From: Lars George <la...@gmail.com>
> To: hbase-dev@hadoop.apache.org
> Sent: Thu, December 17, 2009 4:35:51 PM
> Subject: Encryption
> 
> Hey,
> 
> I was wondering if along with the DAC or before you ever considered
> encrypting data? Like the compression, have a ColFam parameter that
> specifies the encryption and the required details (password or
> certificate/key) and it transparently encrypts the data written to DFS. We
> did talk about this during the Munich OpenHUG and I was curious to know if
> there was ever something like this considered.
> 
> Lars