The current security code supports per-column-qualifier ACLs, though not the
pattern matching approach you describe. It's simply an exact match on
As an alternative (which would work with the current code), you could
segment each set of access patterns to a separate column family, then set
ACLs on the column family level. Of course this might not scale for many
different sets of column patterns. The current recommendation is to have at
most "a few" column families per table, but ideally just one family unless
you really, really need more.
But doing a lot of regexes to match patterns on every single KeyValue is
bound to have scalability problems of it's own. I don't think it would be
all that difficult if someone wanted to add pattern-based ACLs, but we don't
have any plans for it at the moment.
Please let us know how it goes and if there's anything we can help with!
On Mon, Jun 20, 2011 at 10:06 AM, Bill Graham <[EMAIL PROTECTED]> wrote:
> Thanks Dean, that sounds similar to the approach we're considering.
> Andy, I can see value in having ACLs on a per-column-pattern (or maybe just
> per-prefix to make multiple pattern conflict resolution simpler) basis. I
> know this isn't in scope for the initial release, but would the current
> design lend itself to be extended for this case? The use case is where a
> column prefix naming scheme is used for example, and certain groups should
> have write access to certain prefix patterns.
> On Sun, Jun 19, 2011 at 2:48 PM, Hiller, Dean x66079 <
> [EMAIL PROTECTED]> wrote:
> > I don't know if it is good or bad but we went down a route of all keys
> > prefixed or postfixed with "customerId"....prefixed if you want their
> > more isolated or postfixed if you want them sharing the same grid more
> > more.
> > We had some shared tables that are not postfixed nor prefixed and are
> > touched by a committee when needed for everyone...obviously tradeoff in
> > doing that.
> > Later,
> > Dean
> > -----Original Message-----
> > From: Otis Gospodnetic [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, June 17, 2011 9:55 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: any multitenancy suggestions for HBase?
> > Hi Bill,
> > At the recent HBase hackathon in Berlin there was some word of ACLs in
> > next release of?) HBase from the Trend Micro guys, I believe.
> > Check this:
> > Otis
> > --
> > We're hiring HBase / Hadoop / Hive / Mahout engineers with interest in
> > Data Mining and Analytics
> > >________________________________
> > >From: Bill Graham <[EMAIL PROTECTED]>
> > >To: [EMAIL PROTECTED]
> > >Sent: Monday, June 13, 2011 6:31 PM
> > >Subject: any multitenancy suggestions for HBase?
> > >
> > >Hello there,
> > >
> > >We have a number of different groups within our organization who will
> > >be working within the same HBase cluster and we're trying to set up some
> > >best practices to keep thinks organized. Since there are no HBase ACLs
> > and
> > >no concept of multiple databases in the cluster, we're looking to
> > a
> > >simple convention that will hopefully keep people from stepping on each
> > >others toes (or worse!).
> > >
> > >Does anyone have any best/worst practices they're willing to share
> > >thing likes table/column naming schemes in a multitenant environment?
> > >table names for example, is there anything better than a basic
> > dot-delimited
> > >naming convention with the group name as the first token?
> > >
> > >Also, I assume there's no performance cost with using long table names
> > like
> > >there is with long CF:col names. Please let me know if that's not the
> > case.