zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@apache.org>
Subject Re: Zookeeper 3.5 SSL and Kerberos authentication
Date Tue, 17 Dec 2019 17:58:37 GMT
"We were using early 3.5.3 or something like that.”

Netty stack had a major refactor in 3.5.5

Andor



> On 2019. Dec 17., at 16:40, Enrico Olivelli <eolivelli@gmail.com> wrote:
> 
> Il giorno mar 17 dic 2019 alle ore 16:26 Szalay-Bekő Máté <
> szalay.beko.mate@gmail.com> ha scritto:
> 
>> I added a comment on Jira. This is something we will also need to fix in my
>> company soon.
>> 
>> @enrico you wrote:
>>> in my company we set up some ZK with TLS and SASL, using TLS for
>> encryption and SASL for auth. We were using early 3.5.3 or something like
>> that.
>> 
> 
> Unfortunately we do not have that setup anymore, we had to drop it because
> at that time (and still nowadays) from the same JVMs we had also to connect
> to an HBase cluster with ZK 3.4
> that does not support TLS.
> 
> Currently we are using only SASL and not TLS
> Sorry
> 
> Enrico
> 
> 
>> 
>> According to this, the scenario should work. Maybe we just misconfigured
>> something, or this was something got broken in a later version? Can you
>> share the config you use? Maybe you are setting `zookeeper.ssl.clientAuth`
>> and `zookeeper.ssl.quorum.clientAuth` to `none` or `want` ?
>> 
>> Regards,
>> Mate
>> 
>> On Tue, Dec 17, 2019 at 10:48 AM Andor Molnar <andor@apache.org> wrote:
>> 
>>> Hi Jorn,
>>> 
>>> Sorry for coming back late to this. I’ve just validated the scenario on
>> my
>>> test cluster. Looks like the issue is valid: Kerberos auth and SSL are
>>> mutually exclusive currently. When Kerberos is set up and trying to
>> connect
>>> to secure port I got an infinite loop on client side:
>>> 
>>> 2019-12-17 01:43:30,984 [myid:barbaresco-1.vpc.cloudera.com:2182] - WARN
>>> [Thread-39:Login$1@197] - TGT renewal thread has been interrupted and
>>> will exit.
>>> 2019-12-17 01:43:30,987 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO
>>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182):Login@302] - Client
>>> successfully logged in.
>>> 2019-12-17 01:43:30,987 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO
>>> [Thread-40:Login$1@135] - TGT refresh thread started.
>>> 2019-12-17 01:43:30,987 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO
>>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182):SecurityUtils$1@124
>> ]
>>> - Client will use GSSAPI as SASL mechanism.
>>> 2019-12-17 01:43:30,988 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO
>>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182
>>> ):ClientCnxn$SendThread@1112] - Opening socket connection to server
>>> barbaresco-1.vpc.cloudera.com/10.65.25.98:2182. Will attempt to
>>> SASL-authenticate using Login Context section 'Client'
>>> 2019-12-17 01:43:30,988 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO
>>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182
>>> ):ClientCnxn$SendThread@959] - Socket connection established, initiating
>>> session, client: /10.65.25.98:45362, server:
>>> barbaresco-1.vpc.cloudera.com/10.65.25.98:2182
>>> 2019-12-17
>>> <http://barbaresco-1.vpc.cloudera.com/10.65.25.98:21822019-12-17>
>>> 01:43:30,989 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO
>>> [Thread-40:Login@320] - TGT valid starting at:        Tue Dec 17
>> 01:43:30
>>> PST 2019
>>> 2019-12-17 01:43:30,989 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO
>>> [Thread-40:Login@321] - TGT expires:                  Thu Jan 16
>> 01:43:30
>>> PST 2020
>>> 2019-12-17 01:43:30,989 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO
>>> [Thread-40:Login$1@193] - TGT refresh sleeping until: Fri Jan 10
>> 20:23:33
>>> PST 2020
>>> 2019-12-17 01:43:30,989 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO
>>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182
>>> ):ClientCnxn$SendThread@1240] - Unable to read additional data from
>>> server sessionid 0x0, likely server has closed socket, closing socket
>>> connection and attempting reconnect
>>> 
>>> And the following error on server side:
>>> 
>>> 2019-12-17 01:43:33,002 INFO
>>> org.apache.zookeeper.server.NettyServerCnxnFactory: SSL handler added for
>>> channel: [id: 0xcf37c14b, L:/10.65.25.98:2182 - R:/10.65.25.98:45380]
>>> 2019-12-17 01:43:33,003 ERROR
>>> org.apache.zookeeper.server.NettyServerCnxnFactory: Unsuccessful
>> handshake
>>> with session 0x0
>>> 2019-12-17 01:43:33,003 WARN
>>> org.apache.zookeeper.server.NettyServerCnxnFactory: Exception caught
>>> io.netty.handler.codec.DecoderException:
>>> io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record:
>>> 
>> 0000002d000000000000000000000000000075300000000000000000000000100000000000000000000000000000000000
>>>        at
>>> 
>> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:475)
>>>        at
>>> 
>> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:283)
>>>        at
>>> 
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>>>        at
>>> 
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
>>>        at
>>> 
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
>>>        at
>>> 
>> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1422)
>>>        at
>>> 
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
>>>        at
>>> 
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
>>>        at
>>> 
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:931)
>>>        at
>>> 
>> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792)
>>>        at
>>> 
>> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:483)
>>>        at
>>> io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:383)
>>>        at
>>> 
>> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
>>>        at
>>> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>>>        at
>>> 
>> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>>>        at java.lang.Thread.run(Thread.java:748)
>>> 
>>> I will update the Jira too.
>>> 
>>> Andor
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 2019. Nov 8., at 20:31, Jörn Franke <jornfranke@gmail.com> wrote:
>>>> 
>>>> Thanks. Can you please share the configuration file?
>>>> 
>>>> I tried with 3.5.5 - without SSL Kerberos works, but once I configured
>>> client ssl it said authentication fail (I have to check if I can dig up
>> the
>>> log files) and as far as I remember this was related to x509
>>> authentication. The certificate and truststore themselves are fine (I
>> think
>>> I needed to convert the truststore to jks).
>>>> Sorry it was some time ago, I should have separated the log files.
>>>> For me it did not matter that the ports are separated, but it worked on
>>> the non-ssl port fine.
>>>> 
>>>>> Am 06.11.2019 um 23:08 schrieb Enrico Olivelli <eolivelli@gmail.com>:
>>>>> 
>>>>> Jorn,
>>>>> IIRC in my company we set up some ZK with TLS and SASL, using TLS for
>>>>> encryption and SASL for auth.
>>>>> We were using early 3.5.3 or something like that.
>>>>> 
>>>>> Do you have a specific error?
>>>>> 
>>>>> I can also add that in 3.6.0 we will have port-unification, this way
>> you
>>>>> can configure only one client port and accept plain text and TLS
>>> connection
>>>>> from clients (this helps the ttransition to TLS)
>>>>> 
>>>>> Enrico
>>>>> 
>>>>> Il mer 6 nov 2019, 22:28 Jörn Franke <jornfranke@gmail.com> ha
>> scritto:
>>>>> 
>>>>>> Dear all,
>>>>>> 
>>>>>> it seems that ZooKeeper 3.5 with SSL enabled does not support
>> Kerberos
>>>>>> authentication, but only X509 authentication. Kerberos is used in
>> many
>>>>>> Enterprise environments and is supported by Apache Solr. Is this
a
>>> bug? Or
>>>>>> am I missing something?
>>>>>> 
>>>>>> 
>>>>>> I created a Jira for this:
>>>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-3482
>>>>>> 
>>>>>> 
>>>>>> thank you.
>>>>>> 
>>>>>> best regards
>>>>>> 
>>> 
>>> 
>> 


Mime
View raw message