zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arpit Jain <jain.arp...@gmail.com>
Subject Re: Zookeeper and curator SASL authentication
Date Tue, 14 Jan 2020 13:47:59 GMT
Thanks for the clarification.
I am able to authenticate client with Zookeeper. However, when I started to
set ACLs with the same client, I get error messages. This is how I am
creating curator client for setting ACLs

        CuratorFrameworkFactory.Builder builder =

            CuratorFrameworkFactory.builder().connectString(coordinatorHosts
).retryPolicy(retryPolicy)

            .connectionTimeoutMs(coordinatorConnectionTimeout
).sessionTimeoutMs(coordinatorSessionTimeout);

        final CuratorFramework curatorFramework =

            builder.authorization("sasl", "zkclient/zoo1@EXAMPLE.COM"
.getBytes()).aclProvider(new ACLProvider() {

            @Override

            public List<ACL> getDefaultAcl() {

                return ZooDefs.Ids.CREATOR_ALL_ACL;

            }


            @Override

            public List<ACL> getAclForPath(String path) {

                return ZooDefs.Ids.CREATOR_ALL_ACL;

            }

        }).build();


 I see below logs in Zookeeper node:





*2020-01-14 13:27:53,174 [myid:1] - INFO
 [NIOWorkerThread-3:SaslServerCallbackHandler@120] - Successfully
authenticated client: authenticationID=zkclient/zoo1@EXAMPLE.COM
<zoo1@EXAMPLE.COM>;  authorizationID=zkclient/zoo1@EXAMPLE.COM
<zoo1@EXAMPLE.COM>.2020-01-14 13:27:53,175 [myid:1] - INFO
 [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting authorizedID:
zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>2020-01-14 13:27:53,175
[myid:1] - INFO  [NIOWorkerThread-3:ZooKeeperServer@1170] - adding SASL
authorization for authorizationID: zkclient/zoo1@EXAMPLE.COM
<zoo1@EXAMPLE.COM>2020-01-14 13:27:53,182 [myid:1] - INFO
 [NIOWorkerThread-7:ZooKeeperServer@1095] - got auth packet
/172.30.0.6:36658 <http://172.30.0.6:36658>2020-01-14 13:27:53,183 [myid:1]
- WARN  [NIOWorkerThread-7:ZooKeeperServer@1123] - Authentication failed
for scheme: sasl*

Is this not the correct way to do it ?



On Tue, Jan 14, 2020 at 11:52 AM Szalay-Bekő Máté <
szalay.beko.mate@gmail.com> wrote:

> The system property name is a bit misleading... this parameter is actually
> specifies the username used in the ZooKeeper server principal.  (in your
> case the server principal is: zookeeper/zoo1@EXAMPLE.COM)
> AFAIK the ZooKeeper client (after authenticated as zkclient/
> zoo1@EXAMPLE.COM in Kerberos based on the jaas.conf file) needs to know
> the ZooKeeper server principal in order to ask for a specific token from
> kerberos which can be read by the ZooKeeper server.
>
> In 3.5.5 (or 3.5.6) you can use the  zookeeper.sasl.client.username
> parameter (plus some other parameters) to configure how the server
> principal will be determined by the client.
> See:
> https://github.com/apache/zookeeper/blob/c11b7e26bc554b8523dc929761dd28808913f091/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L48
>
> In future releases (3.5.7, 3.6, ...) you can also use
> the zookeeper.server.principal parameter (a much better name I think) to
> use a fix server principal name in the client.
> See:
> https://github.com/apache/zookeeper/blob/1c5d135d74f16275876c024401dc2de92909b20a/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L50
>
> On Mon, Jan 13, 2020 at 6:03 PM Arpit Jain <jain.arpit6@gmail.com> wrote:
>
>> Does this user name have to be "Zookeeper"
>> (-Dzookeeper.sasl.client.username=zookeeper) always ?
>> And the client principal name is different than this username..Correct me
>> if I am wrong ?
>>
>> On Mon, Jan 13, 2020 at 4:58 PM Arpit Jain <jain.arpit6@gmail.com> wrote:
>>
>>> Thanks you so much !
>>> It worked finally. I had to change
>>> -Dzookeeper.sasl.client.username=zookeeper parameter.
>>>
>>> On Mon, Jan 13, 2020 at 4:40 PM Szalay-Bekő Máté <
>>> szalay.beko.mate@gmail.com> wrote:
>>>
>>>> You are using 3.5.5 or 3.5.6, right?
>>>> I think you need to specify: -Dzookeeper.sasl.client.username=zookeeper
>>>> can you give it a try? If it doesn't work then I can take a deeper look
>>>> (also we can enable some debug logging)
>>>>
>>>> On Mon, Jan 13, 2020 at 5:31 PM Arpit Jain <jain.arpit6@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I have Kerberos, Zookeeper and my application (using curator) running
>>>>> in 3 docker containers with ZK SASL authentication enabled. The ZK can
>>>>> login to Kerberos and starts successfully.
>>>>>
>>>>> The ZK server principal is zookeeper/zoo1@EXAMPLE.COM
>>>>> The client principal is : zkclient/zoo1@EXAMPLE.COM
>>>>>
>>>>> While starting my application, I am seeing failure while obtaining
>>>>> TGS.
>>>>> See the log at Kerberos side:
>>>>>
>>>>>
>>>>>
>>>>> *Jan 13 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17})
>>>>> 172.30.0.6 <http://172.30.0.6>: NEEDED_PREAUTH: zkclient/zoo1@EXAMPLE.COM
>>>>> <zoo1@EXAMPLE.COM> for krbtgt/EXAMPLE.COM@EXAMPLE.COM
>>>>> <EXAMPLE.COM@EXAMPLE.COM>, Additional pre-authentication requiredJan
13
>>>>> 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.6
>>>>> <http://172.30.0.6>: ISSUE: authtime 1578928939, etypes {rep=18
tkt=18
>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM> for
>>>>> krbtgt/EXAMPLE.COM@EXAMPLE.COM <EXAMPLE.COM@EXAMPLE.COM>Jan 13
15:22:19 kdc
>>>>> krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.6
>>>>> <http://172.30.0.6>: ISSUE: authtime 1578928939, etypes {rep=18
tkt=18
>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM> for
>>>>> zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>*
>>>>>
>>>>> However, if I use the zkCli.sh to login to Zookeeper, it successfully
>>>>> logs in. See the log on Kerberos side. See the difference in the last
line
>>>>> while requesting TGS.
>>>>>
>>>>>
>>>>>
>>>>> *Jan 13 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17})
>>>>> 172.30.0.3 <http://172.30.0.3>: NEEDED_PREAUTH: zkclient/zoo1@EXAMPLE.COM
>>>>> <zoo1@EXAMPLE.COM> for krbtgt/EXAMPLE.COM@EXAMPLE.COM
>>>>> <EXAMPLE.COM@EXAMPLE.COM>, Additional pre-authentication requiredJan
13
>>>>> 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.3
>>>>> <http://172.30.0.3>: ISSUE: authtime 1578929174, etypes {rep=18
tkt=18
>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM> for
>>>>> krbtgt/EXAMPLE.COM@EXAMPLE.COM <EXAMPLE.COM@EXAMPLE.COM>Jan 13
15:26:14 kdc
>>>>> krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.3
>>>>> <http://172.30.0.3>: ISSUE: authtime 1578929174, etypes {rep=18
tkt=18
>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM> for
>>>>> zookeeper/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>*
>>>>>
>>>>> The client section in JAAS config file is same in both the cases but
>>>>> the server it is looking for is different in both the cases.
>>>>> Could someone suggest why there is a difference ?
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 13, 2020 at 4:17 PM Szalay-Bekő Máté <
>>>>> szalay.beko.mate@gmail.com> wrote:
>>>>>
>>>>>> Also please note, that the
>>>>>> 'Configuration.getConfiguration().refresh()' will reload only the
>>>>>> jaas.config.
>>>>>> If you also need to reload the kerberos client config, then you can
>>>>>> add the "refreshKrb5Config=true" line to your jaas.conf file. This
will
>>>>>> trigger to reload the krb.cfg file as well if needed.
>>>>>>
>>>>>> I am just working on a PR where I had to use both of these:
>>>>>> https://github.com/apache/zookeeper/pull/1204/files#diff-0c01d3c68a71c68701d778cc556c8e0a
>>>>>>
>>>>>> Cheers,
>>>>>> Mate
>>>>>>
>>>>>> On Thu, Jan 9, 2020 at 10:02 PM Damien Diederen <
>>>>>> ddiederen@sinenomine.net> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Enrico,
>>>>>>>
>>>>>>> > There is a method to force JAAS to reload the system property.
>>>>>>> >
>>>>>>> > Something like Configuration.getConfiguration().refresh()
>>>>>>>
>>>>>>> Great to know!  Thanks!
>>>>>>>
>>>>>>> > You have to call that method after changing the system property
>>>>>>>
>>>>>>> Cheers, -D
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> > Il gio 9 gen 2020, 20:05 Damien Diederen <ddiederen@sinenomine.net>
>>>>>>> ha
>>>>>>> > scritto:
>>>>>>> >
>>>>>>> >>
>>>>>>> >> Hi Arpit, Máté,
>>>>>>> >>
>>>>>>> >> Arpit wrote:
>>>>>>> >>
>>>>>>> >> > The solution is to pass JAAS file
>>>>>>> >> > with  -Djava.security.auth.login.config=/path/to/jaas.conf.
>>>>>>> >>
>>>>>>> >> Okay—good.
>>>>>>> >>
>>>>>>> >> > Using System.setProperty does not work for me.
>>>>>>> >>
>>>>>>> >> Ah, I see.  And I'm not surprised; I think Máté is
on the right
>>>>>>> track:
>>>>>>> >>
>>>>>>> >> >> I also faced this exception not long ago. I
think it is an
>>>>>>> edge case,
>>>>>>> >> most
>>>>>>> >> >> probably you have something else, but still...
maybe it helps:
>>>>>>> >> >>
>>>>>>> >> >> I tried to write a unit test which dynamically
generated
>>>>>>> multiple
>>>>>>> >> >> jaas.conf files. Then I was setting the
>>>>>>> >> >> java.security.auth.login.config system property
to the config
>>>>>>> file I
>>>>>>> >> needed
>>>>>>> >> >> in the given testcase, and when I tried to
establish a
>>>>>>> ZooKeeper
>>>>>>> >> connection
>>>>>>> >> >> in the unit test, I also got the same exception
that you got.
>>>>>>> >> >>
>>>>>>> >> >> The problem was, that the security configuration
file I
>>>>>>> referred in the
>>>>>>> >> >> java.security.auth.login.config system property
file was read
>>>>>>> only once,
>>>>>>> >> >> then stored in memory. And it haven't got reloaded,
even if
>>>>>>> the file (or
>>>>>>> >> >> its path in the system property) changed.
>>>>>>> >>
>>>>>>> >> My understanding is that the property is read very early
after
>>>>>>> "VM boot"
>>>>>>> >> (the first time any class tries to access the
>>>>>>> java.security.Provider):
>>>>>>> >> the resource it points to is parsed at that point, and
the
>>>>>>> property
>>>>>>> >> "never" checked again.
>>>>>>> >>
>>>>>>> >> (It *may* be possible to flush the "Spi" or something,
but it's
>>>>>>> clearly
>>>>>>> >> not the kind of usage it was designed for.)
>>>>>>> >>
>>>>>>> >> >> Maybe the best in this case is to
>>>>>>> >> >> specify separate JAAS config sections for each
tests and use a
>>>>>>> single
>>>>>>> >> >> JAAS.conf file per JVM.
>>>>>>> >>
>>>>>>> >> That's probably the easiest if the set is enumerable.
>>>>>>> >>
>>>>>>> >> "Real dynamism" might require overriding the "Spi" or
"Provider,"
>>>>>>> but
>>>>>>> >> that's probably overkill for a few tests.
>>>>>>> >>
>>>>>>> >> (Now that I think of it… our tests are already run
under the
>>>>>>> JMockit
>>>>>>> >> agent, so live-patching JAAS methods using mockit.MockUp
might be
>>>>>>> >> another option :)
>>>>>>> >>
>>>>>>> >> Anyway.  It looks like setting the property externally
worked for
>>>>>>> Arpit.
>>>>>>> >>
>>>>>>> >> Cheers, -D
>>>>>>> >>
>>>>>>>
>>>>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message