Thought as much, thanks very much for taking the time to respond.
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
> which is good).
> I think the question you're ultimately asking is: no, the TenantID
> 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_
> Unless you have a layer in-between Phoenix and your end-users that
> extra guarantees/restrictions, a user could set their own TenantID
> see other folks' data. I don't think this is a good solution for
> 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