Stevo Slavic created KAFKA-4814:
-----------------------------------
Summary: ZookeeperLeaderElector not respecting zookeeper.set.acl
Key: KAFKA-4814
URL: https://issues.apache.org/jira/browse/KAFKA-4814
Project: Kafka
Issue Type: Bug
Components: security
Affects Versions: 0.10.1.1
Reporter: Stevo Slavic
Priority: Minor
By [migration guide|https://kafka.apache.org/documentation/#zk_authz_migration]
for enabling ZooKeeper security on an existing Apache Kafka cluster, and
[broker configuration
documentation|https://kafka.apache.org/documentation/#brokerconfigs] for
{{zookeeper.set.acl}} configuration property, when this property is set to
false Kafka brokers should not be setting any ACLs on ZooKeeper nodes, even
when JAAS config file is provisioned to broker.
Problem is that there is broker side logic, like one in
{{ZookeeperLeaderElector}} making use of {{JaasUtils#isZkSecurityEnabled}},
which does not respect this configuration property, resulting in ACLs being set
even when there's just JAAS config file provisioned to Kafka broker while
{{zookeeper.set.acl}} is set to {{false}}.
Notice that {{JaasUtils}} is in {{org.apache.kafka.common.security}} package of
{{kafka-clients}} module, while {{zookeeper.set.acl}} is broker side only
configuration property.
To make it possible without downtime to enable ZooKeeper authentication on
existing cluster, it should be possible to have all Kafka brokers in cluster
first authenticate to ZooKeeper cluster, without ACLs being set. Only once all
ZooKeeper clients (Kafka brokers and others) are authenticating to ZooKeeper
cluster then ACLs can be started being set.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
