zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli - Diennea <enrico.olive...@diennea.com>
Subject Re: Zookeeper and curator SASL authentication
Date Wed, 15 Jan 2020 12:18:53 GMT
Yes, they are system properties

You can take this guide (about Kafka) as example
https://docs.confluent.io/current/kafka/authentication_sasl/authentication_sasl_gssapi.html



Il giorno 15/01/20, 13:17 "Arpit Jain" <jain.arpit6@gmail.com> ha scritto:

    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.
    >



________________________________

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
View raw message