great! :)
On Wed, Jan 15, 2020 at 6:38 PM Arpit Jain <[email protected]> wrote:
> 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 <
> [email protected]> 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" <[email protected]> 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 <
>> [email protected]> 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" <[email protected]> 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é <
>> > [email protected]>
>> > 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 <
>> [email protected]>
>> > 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/
>> > [email protected]"
>> > >> .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/
>> [email protected]
>> > >> <[email protected]>; authorizationID=zkclient/
>> [email protected]
>> > >> <[email protected]>.2020-01-14 13:27:53,175 [myid:1] - INFO
>> > >> [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting
>> > authorizedID:
>> > >> zkclient/[email protected] <[email protected]>2020-01-14
>> 13:27:53,175
>> > >> [myid:1] - INFO [NIOWorkerThread-3:ZooKeeperServer@1170] -
>> adding
>> > SASL
>> > >> authorization for authorizationID: zkclient/[email protected]
>> > >> <[email protected]>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é <
>> > >> [email protected]> 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/
>> [email protected])
>> > >>> AFAIK the ZooKeeper client (after authenticated as zkclient/
>> > >>> [email protected] 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 <
>> [email protected]>
>> > >>> 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 <
>> [email protected]
>> > >
>> > >>>> 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é <
>> > >>>>> [email protected]> 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 <
>> > [email protected]>
>> > >>>>>> 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/[email protected]
>> > >>>>>>> The client principal is : zkclient/[email protected]
>> > >>>>>>>
>> > >>>>>>> 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/
>> > [email protected]
>> > >>>>>>> <[email protected]> for krbtgt/[email protected]
>> > >>>>>>> <[email protected]>, 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/[email protected] <[email protected]>
>> for
>> > >>>>>>> krbtgt/[email protected] <[email protected]
>> >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/[email protected] <[email protected]>
>> for
>> > >>>>>>> zkclient/[email protected] <[email protected]>*
>> > >>>>>>>
>> > >>>>>>> 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/
>> > [email protected]
>> > >>>>>>> <[email protected]> for krbtgt/[email protected]
>> > >>>>>>> <[email protected]>, 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/[email protected] <[email protected]>
>> for
>> > >>>>>>> krbtgt/[email protected] <[email protected]
>> >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/[email protected] <[email protected]>
>> for
>> > >>>>>>> zookeeper/[email protected] <[email protected]>*
>> > >>>>>>>
>> > >>>>>>> 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é <
>> > >>>>>>> [email protected]> 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 <
>> > >>>>>>>> [email protected]> 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 <
>> > >>>>>>>>> [email protected]> 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.
>>
>
