[jira] [Updated] (KAFKA-4814) ZookeeperLeaderElector not respecting zookeeper.set.acl
[
https://issues.apache.org/jira/browse/KAFKA-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwen Shapira updated KAFKA-4814:
Fix Version/s: (was: 0.10.2.1)
> 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
>Assignee: Rajini Sivaram
> Labels: newbie
> Fix For: 0.11.0.0
>
>
> 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)
[jira] [Updated] (KAFKA-4814) ZookeeperLeaderElector not respecting zookeeper.set.acl
[
https://issues.apache.org/jira/browse/KAFKA-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ismael Juma updated KAFKA-4814:
---
Priority: Major (was: Minor)
> 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
> Labels: newbie
> Fix For: 0.10.3.0, 0.10.2.1
>
>
> 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)
[jira] [Updated] (KAFKA-4814) ZookeeperLeaderElector not respecting zookeeper.set.acl
[
https://issues.apache.org/jira/browse/KAFKA-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ismael Juma updated KAFKA-4814:
---
Fix Version/s: 0.10.2.1
0.10.3.0
> 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
> Labels: newbie
> Fix For: 0.10.3.0, 0.10.2.1
>
>
> 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)
[jira] [Updated] (KAFKA-4814) ZookeeperLeaderElector not respecting zookeeper.set.acl
[
https://issues.apache.org/jira/browse/KAFKA-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ismael Juma updated KAFKA-4814:
---
Labels: newbie (was: )
> 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
> Labels: newbie
> Fix For: 0.10.3.0, 0.10.2.1
>
>
> 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)
