hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Esteban Gutierrez <este...@cloudera.com>
Subject Re: HBase namespaces and encryption
Date Mon, 13 Mar 2017 17:49:38 GMT
Hello Roberta,

I think there are too many caveats of using an encryption zone per
namespace. Specially, bulkloading and the archive will fail; another
problem is about the security guarantees that you are offering to your
tenants, the WALs and oldWALs directories will have to be under the same
encryption zone, not to mention that data from multiple tenants can
potentially be written under the same WAL file and that could difficult to
justify to your tenants. The simplest approach I can think of is to have 3
different HBase clusters and each one pointing to its own encryption zone
on a different hbase.rootdir. I will be necessary to configure
hbase.tmp.dir and zookeeper.znode.parent, port numbers, etc. but I think is
much more simple than specifying an encryption zone per namespace.


Cloudera, Inc.

On Fri, Mar 10, 2017 at 3:11 PM, Roberta Marton <roberta.marton@esgyn.com>

> I have been researching how our product can use namespaces to aid in
> multi-tenancy support.
> For example, I have 3 tenants that need to be isolated from each other.
> Ideally, each tenant would have its own namespace and  its own set of
> permissions applied.
> What I would also like to do is integrate HDFS encryption with
> namespaces.  That is, each namespace would reside in its own encryption
> zone and only be accessible through each zone's encryption key.
> Is this possible?  From the documentation I have been reading, it  is
> recommended that all HBase data be in a single encryption zone. So this
> would preclude the ability to create different zones for each namespace.
> If this is not possible, is there any plans to add this support in the
> future?
> If we can't use HDFS encryption zones, is there any way to isolate each
> tenants data through some other encryption mechanism?
>    Regards,
>    Roberta Marton

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