>> If not possible I guess we have to look at doing something at the HBase
level.
As Josh said, it's not yet supported in Phoenix, Though you may try using
cell-level security of HBase with some Phoenix internal API and let us know
if it works for you.
Sharing a sample code if you wanna try.
/**
* Do writes using cell based ACLs
**/
Properties props = new Properties();
//conf = Hbase conf
PhoenixConnection conn = (PhoenixConnection) QueryUtil.getConnection(props,
conf);
conn.setAutoCommit(false);
conn.createStatement().executeUpdate("<your upsert>");
final Iterator<Pair<byte[],List<Mutation>>> iterator =
pconn.getMutationState().toMutations(false);
while (iterator.hasNext()) {
Pair<byte[], List<Mutation>> kvPair = iterator.next();
List<Mutation> mutationList = kvPair.getSecond();
byte[] tableName = kvPair.getFirst();
for (Mutation mutation : mutationList) {
//perms is user->permissions map
mutation.setACL(perms);
}
htable.batch(mutationList);
}
conn.rollback();
On Tue, Sep 3, 2019 at 3:19 PM Simon Mottram <simon.mott...@cucumber.co.nz>
wrote:
> 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
> > >
>
