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 Wed, 15 Jan 2020 12:16:41 GMT
I have not passed those parameters. Is this something I need to set in
Zookeeper (zoo.cfg) ?

On Wed, Jan 15, 2020 at 12:12 PM Enrico Olivelli - Diennea <
enrico.olivelli@diennea.com> wrote:

> Usually with SASL auth you are using:
> kerberos.removeHostFromPrincipal=true
> kerberos.removeRealmFromPrincipal=true
>
> is this the case for you ?
>
> Enrico
>
> Il giorno 15/01/20, 13:01 "Arpit Jain" <jain.arpit6@gmail.com> ha
> scritto:
>
>     I have asked in Curator mailing list as well but not much help. I am
> able
>     to set ACL with sasl scheme by using zkCli.sh client in Zookeeper
> server.
>     The idea is to use Curator to set the ACLs so that only my client
>     application can access its Znodes.
>
>
>     On Wed, Jan 15, 2020 at 9:21 AM Szalay-Bekő Máté <
> szalay.beko.mate@gmail.com>
>     wrote:
>
>     > I am not sure what is wrong with the code... I am not familiar with
>     > Curator. I can try to google / reproduce this and see what is wrong,
> but it
>     > will take a while for me. So first I would ask the others, maybe
> there is
>     > someone who knows both ZooKeeper SASL and Curator and can help you
> more in
>     > this mailing list. If noone replies, then I will try to setup a dummy
>     > project with Curator to test this.
>     >
>     > Did you also ask around the Curator mailing list maybe? Would it
> help if I
>     > send you code about setting the ACLs using plain ZooKeeper (and no
> Curator)?
>     >
>     > On Tue, Jan 14, 2020 at 2:48 PM Arpit Jain <jain.arpit6@gmail.com>
> wrote:
>     >
>     >> 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
>     >>>>>>>>> >>
>     >>>>>>>>>
>     >>>>>>>>
>
>
>
> ________________________________
>
> CONFIDENTIALITY & PRIVACY NOTICE
> This e-mail (including any attachments) is strictly confidential and may
> also contain privileged information. If you are not the intended recipient
> you are not authorised to read, print, save, process or disclose this
> message. If you have received this message by mistake, please inform the
> sender immediately and destroy this e-mail, its attachments and any copies.
> Any use, distribution, reproduction or disclosure by any person other than
> the intended recipient is strictly prohibited and the person responsible
> may incur in penalties.
> The use of this e-mail is only for professional purposes; there is no
> guarantee that the correspondence towards this e-mail will be read only by
> the recipient, because, under certain circumstances, there may be a need to
> access this email by third subjects belonging to the Company.
>

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