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.olive...@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.arp...@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.olive...@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.arp...@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.m...@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.arp...@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/
> > z...@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/
> z...@example.com
> > >> <z...@example.com>; authorizationID=zkclient/
> z...@example.com
> > >> <z...@example.com>.2020-01-14 13:27:53,175 [myid:1] - INFO
> > >> [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting
> > authorizedID:
> > >> zkclient/z...@example.com <z...@example.com>2020-01-14
> 13:27:53,175
> > >> [myid:1] - INFO [NIOWorkerThread-3:ZooKeeperServer@1170] -
> adding
> > SASL
> > >> authorization for authorizationID: zkclient/z...@example.com
> > >> <z...@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.m...@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/
> z...@example.com)
> > >>> AFAIK the ZooKeeper client (after authenticated as zkclient/
> > >>> z...@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.arp...@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.arp...@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.m...@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.arp...@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/z...@example.com
> > >>>>>>> The client principal is : zkclient/z...@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/
> > z...@example.com
> > >>>>>>> <z...@example.com> for krbtgt/example....@example.com
> > >>>>>>> <example....@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/z...@example.com <z...@example.com>
> for
> > >>>>>>> krbtgt/example....@example.com <example....@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/z...@example.com <z...@example.com>
> for
> > >>>>>>> zkclient/z...@example.com <z...@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/
> > z...@example.com
> > >>>>>>> <z...@example.com> for krbtgt/example....@example.com
> > >>>>>>> <example....@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/z...@example.com <z...@example.com>
> for
> > >>>>>>> krbtgt/example....@example.com <example....@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/z...@example.com <z...@example.com>
> for
> > >>>>>>> zookeeper/z...@example.com <z...@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.m...@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 <
> > >>>>>>>> ddiede...@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 <
> > >>>>>>>>> ddiede...@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.
>
