On Tue, Dec 13, 2016 at 9:53 PM, Amit Adhau <[email protected]> wrote:
> Thank you Todd. > > If required can you please suggest any solution for Kudu, where security > can be implemented at kudu level? > Currently there is no such solution. You'll have to provide it at a higher layer or wait until Kudu supports security features. > > Does the simple LDAP authentication will work for kudu? we have the java > consumer which ingest the data to kudu and rest call which gets the data > from kudu. > Nope, no LDAP integration. > > Or Can the security at the call level to the kudu can be implemented? > Not yet. > > Thank you for your help. This is something which we need for our prod > cluster where some level of security is necessary for kudu. > > Sounds like for this application you may need to wait until a future version has the features you need. -Todd > Thank you, > Amit > > On Tue, Dec 13, 2016 at 10:11 AM, Todd Lipcon <[email protected]> wrote: > >> On Mon, Dec 12, 2016 at 11:54 PM, Amit Adhau <[email protected]> >> wrote: >> >>> Thanks a lot Todd. >>> >>> In case of dedicated kudu masters and tablets just wondering does the >>> 32GB RAM[masters] >>> >> and 64GB[Tablets, understood this will be dependant on data, process etc. >>> ] will be sufficient >>> >> ? >>> >> >> Sure, we often run test clusters with less dedicated RAM than this and it >> works fine. >> >> -Todd >> >> >>> >>> Thanks, >>> Amit >>> >>> On Mon, Dec 12, 2016 at 11:34 AM, Todd Lipcon <[email protected]> wrote: >>> >>>> On Sun, Dec 4, 2016 at 11:40 PM, Amit Adhau <[email protected]> >>>> 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 <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Amit. Answers below. >>>>>> >>>>>> On Sat, Dec 3, 2016 at 9:16 AM, Amit Adhau <[email protected]> >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > Thanks & Regards, > > *Amit Adhau* | Data Architect > > *GLOBANT* | IND:+91 9821518132 <+91%2098215%2018132> > > [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
