>> 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.Mottram@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
> >