phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Multi-Tenancy and shared records
Date Tue, 03 Sep 2019 15:19:18 GMT
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

View raw message