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 Mon, 12 Dec 2016 06:04:23 GMT
On Sun, Dec 4, 2016 at 11:40 PM, Amit Adhau <amit.adhau@globant.com> wrote:

> Thank you Todd,
>
> In case of, using non-Kerberized Kudu alongside Kerberized
> Impala/HDFS/etc - Are you saying that we can have kudu masters and kudu
> tablets outside of the kerberos enabled HDFS instances, but then I guess
> kudu will not be part of same cloudera cluster and I would probably need
> another cloudera cluster without kerberos enabled on it.
>

Kudu doesn't store data on HDFS, so whether HDFS or kerberized or not
wouldn't have any effect on Kudu. You can install a non-Kerberized Kudu
service on the same hosts where a Kerberized HDFS/YARN/etc are running.

As for Cloudera specifics, the "enable Kerberos" wizard in CM won't do
anything to your Kudu service. It will keep running without Kerberos even
though the rest of the services are kerberized.

>
> May be a silly question but, In my case I have the consumers which are
> reading data from kafka[Here, kerberos enabled instances] and then pushing
> it to kudu[non-kerberos enabled instances], will there be any issue[may be
> latency issue] in this cross kerberos - nonkerberos cluster communication?
>

Should not have any negative effect. There's no "conversion" or anything to
worry about.


>
> Do you have any reference or details that what could be the precaution
> that needs to be taken or how can we do it?
>

It ought to "just work" so there are no specific docs.

-Todd



> On Sun, Dec 4, 2016 at 10:00 AM, Todd Lipcon <todd@cloudera.com> wrote:
>
>> 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
>>
>
>
>
> --
> Thanks & Regards,
>
> *Amit Adhau* | Data Architect
>
> *GLOBANT* | IND:+91 9821518132
>
> [image: Facebook] <https://www.facebook.com/Globant>
>
> [image: Twitter] <http://www.twitter.com/globant>
>
> [image: Youtube] <http://www.youtube.com/Globant>
>
> [image: Linkedin] <http://www.linkedin.com/company/globant>
>
> [image: Pinterest] <http://pinterest.com/globant/>
>
> [image: Globant] <http://www.globant.com/>
>
> The information contained in this e-mail may be confidential. It has been
> sent for the sole use of the intended recipient(s). If the reader of this
> message is not an intended recipient, you are hereby notified that any
> unauthorized review, use, disclosure, dissemination, distribution or
> copying of this communication, or any of its contents,
> is strictly prohibited. If you have received it by mistake please let us
> know by e-mail immediately and delete it from your system. Many thanks.
>
>
>
> La información contenida en este mensaje puede ser confidencial. Ha sido
> enviada para el uso exclusivo del destinatario(s) previsto. Si el lector de
> este mensaje no fuera el destinatario previsto, por el presente queda Ud.
> notificado que cualquier lectura, uso, publicación, diseminación,
> distribución o copiado de esta comunicación o su contenido está
> estrictamente prohibido. En caso de que Ud. hubiera recibido este mensaje
> por error le agradeceremos notificarnos por e-mail inmediatamente y
> eliminarlo de su sistema. Muchas gracias.
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Mime
View raw message