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 17:38:19 GMT
I managed to create ACL with authenticated client principal using below
lines of code in client:

            curator
.create().creatingParentContainersIfNeeded().withACL(ZooDefs.Ids.
CREATOR_ALL_ACL).forPath("/mynode");


ZooDefs.Ids.CREATOR_ALL_ACL gives permissions to the client which is
authenticated.

To test this, I logged in using zkCli.sh on ZK server and ran getAcl
/mynode and able to browse the znodes and can see that node has all (CDRWA)
permission for authenticated uses. If I log in with a unauthenticated
principal, I am not able to see the znodes tree even though I manage to
connect to ZK server.

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

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message