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 > >
