[
https://issues.apache.org/jira/browse/KAFKA-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034514#comment-17034514
]
Ron Dagostino commented on KAFKA-9515:
--------------------------------------
[~ijuma] I have learned something since [~rsivaram] and I discussed this in the
above-referenced PR. Specifically, if someone tries to run the ZK Security
Migrator tool with no SASL creds but with a client cert, while at the same time
ZooKeeper 3.5.7 specifies ssl.clientAuth=none, then the migrator tool fails and
ACls are not applied. This is the stack trace I see:
org.apache.zookeeper.KeeperException$InvalidACLException: KeeperErrorCode =
InvalidACL for /admin
at org.apache.zookeeper.KeeperException.create(KeeperException.java:128)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)
at kafka.zookeeper.AsyncResponse.maybeThrow(ZooKeeperClient.scala:564)
at kafka.zk.KafkaZkClient.createRecursive(KafkaZkClient.scala:1644)
at
kafka.zk.KafkaZkClient.makeSurePersistentPathExists(KafkaZkClient.scala:1566)
at
kafka.admin.ZkSecurityMigrator.$anonfun$run$4(ZkSecurityMigrator.scala:270)
at
kafka.admin.ZkSecurityMigrator.$anonfun$run$4$adapted(ZkSecurityMigrator.scala:265)
at scala.collection.immutable.List.foreach(List.scala:392)
at
kafka.admin.ZkSecurityMigrator.kafka$admin$ZkSecurityMigrator$$run(ZkSecurityMigrator.scala:265)
at kafka.admin.ZkSecurityMigrator$.run(ZkSecurityMigrator.scala:110)
at kafka.admin.ZkSecurityMigrator$.main(ZkSecurityMigrator.scala:115)
at kafka.admin.ZkSecurityMigrator.main(ZkSecurityMigrator.scala)
So we don't have to worry about the case of someone thinking they applied ACLs
when in fact they have not -- they can never be confused about that due to the
above error being raised, so if ssl.clientAuth=none on the ZooKeeper side they
must have set SASL credentials for it to succeed, and the SASL user will be
ACL'ed in ZooKeeper.
The other case to think about is after ACLs have been applied successfully and
Kafka connects with zookeeper.set.acl=true. The possibilities here are they
set a SASL credential with or without a client cert or they don't set a SASL
credential with a client cert. If they set a SASL credential then all is good
-- the SASL user has ben ACl'ed and it works fine. If they don't set a SASL
credential then they are connecting with the client cert, and of course that
won't be ACL'ed (and if ssl.clientAuth=none in ZooKeeper then they are
connecting unauthenticated anyway) -- and Kafka will fail to start. I think
that is fine because the thing we had to worry about is a potential breach of
security: someone thinking they were setting up ZooKeeper with secure ACls but
they actually ended up creating ACls for World read/write access. As we can
see from the above, this is actually impossible.
So assuming I haven't missed anything or made a mistake, I think the only thing
we would need to do is some doc changes to let people know about
ssl.clientAuth=[want|need|none] being operational.
> Upgrade ZooKeeper to 3.5.7
> --------------------------
>
> Key: KAFKA-9515
> URL: https://issues.apache.org/jira/browse/KAFKA-9515
> Project: Kafka
> Issue Type: Improvement
> Reporter: Ismael Juma
> Assignee: Ismael Juma
> Priority: Blocker
> Fix For: 2.5.0, 2.4.1
>
>
> There are some critical fixes in ZK 3.5.7 and the first RC has been posted:
> [https://mail-archives.apache.org/mod_mbox/zookeeper-dev/202002.mbox/%3cCAGH6_KiULzemT-V4x_2ybWeKLMvQ+eh=q-dzsiz8a-ypp5t...@mail.gmail.com%3e]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
