phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Mottram <Simon.Mott...@cucumber.co.nz>
Subject Re: Multi-Tenancy and shared records
Date Tue, 03 Sep 2019 22:19:02 GMT
Hi Josh

Thought as much, thanks very much for taking the time to respond.

Appreciated

Simon

On Tue, 2019-09-03 at 11:19 -0400, Josh Elser wrote:
> Hi Simon,
> 
> Phoenix does not provide any authorization/security layers on top of 
> what HBase does (the thread on user@hbase has a suggestion on cell
> ACLs 
> which is good).
> 
> I think the question you're ultimately asking is: no, the TenantID
> is 
> not an authorization layer. In a nut-shell, the TenantID is just an 
> extra attribute (column) added to your primary key constraint 
> auto-magically. If a user doesn't set a TenantID, then they see _all_
> data.
> 
> Unless you have a layer in-between Phoenix and your end-users that
> add 
> extra guarantees/restrictions, a user could set their own TenantID
> and 
> see other folks' data. I don't think this is a good solution for
> what 
> you're trying to accomplish.
> 
> On 9/2/19 8:34 PM, Simon Mottram wrote:
> > Hi
> > 
> > I'm working on a project where we have a combination of very sparse
> > data columns with added headaches of multi-tenancy.  Hbase looks
> > great
> > for the back end but I need to check that we can support the
> > customer's
> > multi-tenancy requirements.
> > 
> > There are 2 that I'm struggling to find a definitive answer for.
> > Any
> > info most gratefully received
> > 
> > Shared Data
> > ===========
> > Each record in the table must be secured but it could be multiple
> > tenants for a record.  Think 'shared' data.
> > 
> > So for example if you had 3 records
> > 
> > record1, some secret data
> > record2, some other secret data
> > record3, data? what data.
> > 
> > We need
> > user1 to be able to see record1 and record2
> > user2 to be able to see record2 and record3
> > 
> >  From what I see in the mult-tenancy doco, the tenant_id field is a
> > VARCHAR,  can this be multiple values?
> > 
> > The actual 'multiple tenant' value would be set at creation and
> > very
> > rarely (if ever) changed, but I couldn't guarantee immutability
> > 
> > 
> > Enforced Security
> > =================
> > Can you prevent access without TenantId?  Otherwise if someone just
> > edits the connection info they can sidestep all the multi-tenancy
> > features.   Our users include scientific types who will want to
> > connect
> > directly using JDBC/Python/Other so we need to be sure to lock this
> > data down.
> > 
> > Of course they want 'admin' types who CAN see all =) Whether there
> > is a
> > special connection that allows non-tenanted connections or have a
> > multi-tenant key that always contains a master tenantid (yuck)
> > 
> > If not possible I guess we have to look at doing something at the
> > HBase
> > level.
> > 
> > Best Regards
> > 
> > Simon
> > 
Mime
View raw message