You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@phoenix.apache.org by Lars George <la...@gmail.com> on 2017/10/22 08:07:52 UTC
Phoenix system tables in multitenant setup
Hi,
I am wondering, in a secured cluster with Kerberos and HBase ACLs, and
with namespace mapping enabled in Phoenix, what is needed to enable
users to create their own tables in a "schema"? The documentation
(https://phoenix.apache.org/namspace_mapping.html#What_permissions_are_required_to_CREATE_and_DROP_SCHEMA)
states that you need admin permissions in HBase to create the schema,
which makes sense as it creates a namespace in HBase.
But for tables inside, I am assuming the user needs access to the
Phoenix SYSTEM tables (and CREATE rights for the namespace in question
on the HBase level)? Is that the case? And if so, what are they able
to see, as in, only their information, or all information from other
tenants as well? If so, is there a way to truly isolate them?
Oh, and I was wondering why there is no "!schema" or some such. Or am
I missing something?
Cheers,
Lars
Re: Phoenix system tables in multitenant setup
Posted by Lars George <la...@gmail.com>.
Thanks for the information. Just as a side note: this is critical to
use Phoenix in larger organizations, so for it's worth, I vote +1 for
this effort. Good on you.
On Mon, Oct 23, 2017 at 12:25 PM, Andrew Purtell <ap...@apache.org> wrote:
> There is some work in progress* to make it so only global read privilege on
> some SYSTEM tables will be necessary for clients to continue to function
> normally for DML operations. For DDL operations, the embedded Phoenix
> metadata service (MetaDataEndpoint) will modify system tables on behalf of a
> suitably privileged user and also drive standard HBase namespace and table
> administrative actions. Related, Phoenix needs to adopt a permissions model
> and grant management syntax.
>
> * - See PHOENIX-672 and PHOENIX-4198 for two examples.
>
>
> On Mon, Oct 23, 2017 at 12:38 AM, Ankit Singhal <an...@gmail.com>
> wrote:
>>
>> bq. But for tables inside, I am assuming the user needs access to the
>>
>> Phoenix SYSTEM tables (and CREATE rights for the namespace in questio
>> n
>>
>> on the HBase level)? Is that the case? And if so, what are they able
>> to see, as in, only their information, or all information from other
>> tenants as well? If so, is there a way to truly isolate them?
>>
>> Currently, a Phoenix user requires RWCXA on SYSTEM tables, thus, they will
>> be able to see all the schemas and tables for all the tenants by simply
>> running a query against SYSTEM.CATALOG . In order to restrict access against
>> the underlying HBase ACLs, We may need to bring some cell level ACLs or
>> control all access to system tables by some end point having access
>> controller checks(like we do for HBase acl table).
>>
>>
>> On Mon, Oct 23, 2017 at 6:15 AM, Ethan Wang <ae...@gmail.com> wrote:
>>>
>>> !schema sounds like a great idea. For users who has permission to see, to
>>> list all the visible schemas.
>>>
>>>
>>> On October 22, 2017 at 1:07:58 AM, Lars George (lars.george@gmail.com)
>>> wrote:
>>>
>>> Hi,
>>>
>>> I am wondering, in a secured cluster with Kerberos and HBase ACLs, and
>>> with namespace mapping enabled in Phoenix, what is needed to enable
>>> users to create their own tables in a "schema"? The documentation
>>>
>>> (https://phoenix.apache.org/namspace_mapping.html#What_permissions_are_required_to_CREATE_and_DROP_SCHEMA)
>>> states that you need admin permissions in HBase to create the schema,
>>> which makes sense as it creates a namespace in HBase.
>>>
>>> But for tables inside, I am assuming the user needs access to the
>>> Phoenix SYSTEM tables (and CREATE rights for the namespace in question
>>> on the HBase level)? Is that the case? And if so, what are they able
>>> to see, as in, only their information, or all information from other
>>> tenants as well? If so, is there a way to truly isolate them?
>>>
>>> Oh, and I was wondering why there is no "!schema" or some such. Or am
>>> I missing something?
>>>
>>> Cheers,
>>> Lars
>>
>>
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
Re: Phoenix system tables in multitenant setup
Posted by Andrew Purtell <ap...@apache.org>.
There is some work in progress* to make it so only global read privilege on
some SYSTEM tables will be necessary for clients to continue to function
normally for DML operations. For DDL operations, the embedded Phoenix
metadata service (MetaDataEndpoint) will modify system tables on behalf of
a suitably privileged user and also drive standard HBase namespace and
table administrative actions. Related, Phoenix needs to adopt a permissions
model and grant management syntax.
* - See PHOENIX-672 and PHOENIX-4198 for two examples.
On Mon, Oct 23, 2017 at 12:38 AM, Ankit Singhal <an...@gmail.com>
wrote:
> bq. But for tables inside, I am assuming the user needs access to the
>
>
> Phoenix SYSTEM tables (and CREATE rights for the namespace in questio
> n
>
> on the HBase level)? Is that the case? And if so, what are they able
> to see, as in, only their information, or all information from other
> tenants as well? If so, is there a way to truly isolate them?
>
> Currently, a Phoenix user requires RWCXA on SYSTEM tables, thus, they will
> be able to see all the schemas and tables for all the tenants by simply
> running a query against SYSTEM.CATALOG . In order to restrict access
> against the underlying HBase ACLs, We may need to bring some cell level
> ACLs or control all access to system tables by some end point having access
> controller checks(like we do for HBase acl table).
>
>
> On Mon, Oct 23, 2017 at 6:15 AM, Ethan Wang <ae...@gmail.com> wrote:
>
>> !schema sounds like a great idea. For users who has permission to see, to
>> list all the visible schemas.
>>
>>
>> On October 22, 2017 at 1:07:58 AM, Lars George (lars.george@gmail.com)
>> wrote:
>>
>> Hi,
>>
>> I am wondering, in a secured cluster with Kerberos and HBase ACLs, and
>> with namespace mapping enabled in Phoenix, what is needed to enable
>> users to create their own tables in a "schema"? The documentation
>> (https://phoenix.apache.org/namspace_mapping.html#What_permi
>> ssions_are_required_to_CREATE_and_DROP_SCHEMA)
>> states that you need admin permissions in HBase to create the schema,
>> which makes sense as it creates a namespace in HBase.
>>
>> But for tables inside, I am assuming the user needs access to the
>> Phoenix SYSTEM tables (and CREATE rights for the namespace in question
>> on the HBase level)? Is that the case? And if so, what are they able
>> to see, as in, only their information, or all information from other
>> tenants as well? If so, is there a way to truly isolate them?
>>
>> Oh, and I was wondering why there is no "!schema" or some such. Or am
>> I missing something?
>>
>> Cheers,
>> Lars
>>
>>
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: Phoenix system tables in multitenant setup
Posted by Ankit Singhal <an...@gmail.com>.
bq. But for tables inside, I am assuming the user needs access to the
Phoenix SYSTEM tables (and CREATE rights for the namespace in question
on the HBase level)? Is that the case? And if so, what are they able
to see, as in, only their information, or all information from other
tenants as well? If so, is there a way to truly isolate them?
Currently, a Phoenix user requires RWCXA on SYSTEM tables, thus, they will
be able to see all the schemas and tables for all the tenants by simply
running a query against SYSTEM.CATALOG . In order to restrict access
against the underlying HBase ACLs, We may need to bring some cell level
ACLs or control all access to system tables by some end point having access
controller checks(like we do for HBase acl table).
On Mon, Oct 23, 2017 at 6:15 AM, Ethan Wang <ae...@gmail.com> wrote:
> !schema sounds like a great idea. For users who has permission to see, to
> list all the visible schemas.
>
>
> On October 22, 2017 at 1:07:58 AM, Lars George (lars.george@gmail.com)
> wrote:
>
> Hi,
>
> I am wondering, in a secured cluster with Kerberos and HBase ACLs, and
> with namespace mapping enabled in Phoenix, what is needed to enable
> users to create their own tables in a "schema"? The documentation
> (https://phoenix.apache.org/namspace_mapping.html#What_
> permissions_are_required_to_CREATE_and_DROP_SCHEMA)
> states that you need admin permissions in HBase to create the schema,
> which makes sense as it creates a namespace in HBase.
>
> But for tables inside, I am assuming the user needs access to the
> Phoenix SYSTEM tables (and CREATE rights for the namespace in question
> on the HBase level)? Is that the case? And if so, what are they able
> to see, as in, only their information, or all information from other
> tenants as well? If so, is there a way to truly isolate them?
>
> Oh, and I was wondering why there is no "!schema" or some such. Or am
> I missing something?
>
> Cheers,
> Lars
>
>
Re: Phoenix system tables in multitenant setup
Posted by Ethan Wang <ae...@gmail.com>.
!schema sounds like a great idea. For users who has permission to see, to
list all the visible schemas.
On October 22, 2017 at 1:07:58 AM, Lars George (lars.george@gmail.com)
wrote:
Hi,
I am wondering, in a secured cluster with Kerberos and HBase ACLs, and
with namespace mapping enabled in Phoenix, what is needed to enable
users to create their own tables in a "schema"? The documentation
(
https://phoenix.apache.org/namspace_mapping.html#What_permissions_are_required_to_CREATE_and_DROP_SCHEMA)
states that you need admin permissions in HBase to create the schema,
which makes sense as it creates a namespace in HBase.
But for tables inside, I am assuming the user needs access to the
Phoenix SYSTEM tables (and CREATE rights for the namespace in question
on the HBase level)? Is that the case? And if so, what are they able
to see, as in, only their information, or all information from other
tenants as well? If so, is there a way to truly isolate them?
Oh, and I was wondering why there is no "!schema" or some such. Or am
I missing something?
Cheers,
Lars