https://community.cloudera.com/t5/Support-Questions/Kudu-impala-security/m-p/307104#M223085 <P>These are good questions that come up frequently.</P><P>&nbsp;</P><P><A href="https://docs.cloudera.com/runtime/7.2.2/administering-kudu/topics/kudu-security-trusted-users.html" target="_blank">https://docs.cloudera.com/runtime/7.2.2/administering-kudu/topics/kudu-security-trusted-users.html</A>&nbsp;discusses the issue. In summary, Hive/Impala tables (i.e. those with entries in the Hive Metastore) are authorized in the same way, regardless of whether backing storage is HDFS, S3, Kudu, HBase, etc - the SQL interface does the authorization to confirm that the end user has access to the table, columns, etc, then the service accesses the storage as the privileged user (Impala in this case).</P><P>&nbsp;</P><P>In this model, if you create an external Kudu table in Impala and give permissions to a user to access the table via Impala, then they will have permissions to access the data in the underlying Kudu table.<BR /><BR />The thing that closes the loophole here is that creating the external Kudu table requires very high privileges - ALL permission on SERVER - a regular user can't create an external Kudu table pointed at an arbitrary Kudu cluster or table.</P> Mon, 07 Dec 2020 17:17:35 GMT Tim Armstrong 2020-12-07T17:17:35Z