kudu-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: Kudu on kerberos enabled cluster
Date Sun, 04 Dec 2016 04:30:16 GMT
Hi Amit. Answers below.

On Sat, Dec 3, 2016 at 9:16 AM, Amit Adhau <amit.adhau@globant.com> wrote:

> Hi Kudu Team,
>
> We need to deploy our Kudu implementation[With 3 Kudu Masters] to the
> cloudera Kerberos enabled cluster
>

Kudu itself doesn't support Kerberos authentication yet. There's been some
progress made in trunk in the last month or so, but it's not ready for
general use until we do quite a bit more work over the coming months.

That said, I know of clusters using non-Kerberized Kudu alongside
Kerberized Impala/HDFS/etc, so that should work fine with no special
configuration. Please report back if you run into any issues.


> also, we will be using Sentry for authorization.
>

Sentry authorization does not integrate with Kudu yet. We hope to add this
integration down the road but it hasn't been started as of yet.

One of the main complexities is that a single Kudu table could be "mapped"
to multiple tables in the Hive metastore. So, even if you were to do the
following:

CREATE TABLE my_table (x int, primary key (x)) STORED AS KUDU;
GRANT SELECT ON my_table TO foo_user

... then some other user could come along and do:

CREATE EXTERNAL TABLE evil_second_table STORED AS KUDU TBLPROPERTIES
('kudu.table_name'='my_table');

and apply their own permissions to the second mapping table.

Given this, we don't recommend using Kudu for applications that require
strong access control yet at this layer. Of course it can be used if access
control is provided at a higher layer (eg only allow network access to the
cluster from a specific set of hosts which have restricted login access).

Thanks
-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Mime
View raw message