How to configure Sentry to allow creating a Kudu tables using Impala

[#1]

Hi,

we have a sentry role that have action=ALL on db=my_db

When trying to issue a CREATE TABLE statment in Impala to create a Kudu table in my_db we get the following error:

I1205 12:32:21.124711 47537 jni-util.cc:176] org.apache.impala.catalog.AuthorizationException: User 'my_user' does not have privileges to access: name_of_sentry_server

A work-around is to set action=ALL on the server level to the sentry role but we don't want to give this wide permission to the role.

Do we need to set action=ALL on the server level in order to delegate the rights to our users to create Kudu tables or how could we set up Sentry in this case?

We use CDH 5.12.1 (Kudu 1.4.0)

Br,

Petter

[#2]

Hi Pettax,

To have a more fine-grained sentry privilege setup, you can grant "ALL" (or "Select","Insert", whichever suits your use case) privilege to the group the user ('my_user') belongs to.

Also, I think this doc may be helpful for you to get more context of how to use Sentry, https://www.cloudera.com/documentation/enterprise/latest/topics/cm_sg_sentry_service.html#id_r3w_kww....

Best,

Hao

[#3]

Hi Pettax,

Sorry, I missed that you are using external Kudu tables in the previous reply. If you are using 5.12, there is this limitation that "Only users with ALL privileges on SERVER may create external Kudu tables." you can check here for more reference: https://www.cloudera.com/documentation/kudu/latest/topics/kudu_impala.html#concept_mpl_zxk_mz.

[#4]

Hi,

thank you for your reply!

>Sorry, I missed that you are using external Kudu tables in the previous reply.

They are in fact internal tables. I do not use the EXTERNAL keyword when creating the tables.

The only way I can let one user group (ROLE in Sentry) create their own Kudu tables (via Impala) is to give the ALL privilegies on the server level. This has the side effect that this user group will enyoy access to all data on the cluster. This is not desired.

Granting ALL on the (impala) db level does not help.

Have I missed something? Will finer grained access arrive in the future?

Br,

Petter

[#5]

Hi Petter,

Would you mind sharing the query how you create a new table? Did you happen to set kudu master addresses in TBLPROPERTIES clause?

> Will finer grained access arrive in the future?

Yes, we have a jira to trap finer grained authorization intergation in Kudu, https://issues.apache.org/jira/browse/KUDU-428. It is on Kudu's roadmap. Once this is done, I believe this limitation you are hitting via impala will be relaxed.

Best,

Hao 

[#6]

Hi,

>Would you mind sharing the query how you create a new table? Did you happen to set kudu master addresses in TBLPROPERTIES clause?

I did use the TBLPROPERTIES clause. I read somewhere that it should not be needed if running in a CM environment but in our case we have to specify it. I see now that CM has not added the --tserver_master_addrs flas to the gflagfile. See belwo for a simplified CREATE TABLE statement.

CREATE TABLE my_db.my_table
(
  key BIGINT,
  value STRING,
  PRIMARY KEY(key)
)
PARTITION BY RANGE (key)
(
   PARTITION 1 <= VALUES < 1000
)
STORED AS KUDU
TBLPROPERTIES ('kudu.master_addresses'='my-master-address');

Are you saying that it will work (with Sentry) if we add the --tserver_master_addrs to the tservers and remove the TBLPROPERTIES clause?

Br,

Petter

[#7 · Accepted solution]

Hi Petter,

Right, based on my understanding of how Impala Kudu intergration works, if you remove TBLPROPERTIES clause (and set Kudu master address on the tservers), it won't require ALL privileges on SERVER for users to create an internal table. Let me know if it does not work.

Best,

Hao

[#8]

Hi,

great! It solved my problem!

For other users in the future:

We upgraded a 5.10.1 cluster (without Kudu) to a 5.12.1 cluster (with Kudu). The missing part was the configuration option 'Kudu Service' that was set to none in the Impala Service-Wide configuration. Setting this to Kudu insert the impalad startup option -kudu_master_hosts and after that I can create tables without the TBLPROPERTIES clause and Sentry now works as expected.

Thank you very much, Hao!

[#9]

Hi @Pettax

Thanks, your solution work with me too.