Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 2D032200C54 for ; Wed, 12 Apr 2017 13:00:53 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2BA05160B8A; Wed, 12 Apr 2017 11:00:53 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 738B1160B95 for ; Wed, 12 Apr 2017 13:00:52 +0200 (CEST) Received: (qmail 51326 invoked by uid 500); 12 Apr 2017 11:00:51 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 51314 invoked by uid 99); 12 Apr 2017 11:00:51 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Apr 2017 11:00:51 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id CDA231AFC49 for ; Wed, 12 Apr 2017 11:00:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id f6Im-jYzqlsM for ; Wed, 12 Apr 2017 11:00:49 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id AFC0060CE8 for ; Wed, 12 Apr 2017 11:00:48 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 0C2CFE095D for ; Wed, 12 Apr 2017 11:00:48 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 201F62407A for ; Wed, 12 Apr 2017 11:00:47 +0000 (UTC) Date: Wed, 12 Apr 2017 11:00:47 +0000 (UTC) From: "Balint Molnar (JIRA)" To: dev@kafka.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (KAFKA-4814) ZookeeperLeaderElector not respecting zookeeper.set.acl MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 12 Apr 2017 11:00:53 -0000 [ https://issues.apache.org/jira/browse/KAFKA-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965664#comment-15965664 ] Balint Molnar commented on KAFKA-4814: -------------------------------------- [~rsivaram] I think if we change JaasUtils.isZkSecurityEnabled function to controllerContext.zkUtils.isSecure does the trick https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/server/ZookeeperLeaderElector.scala#L81. But I am not 100% sure about that. On the other hand maybe it is a good to wait until KAFKA-5028 is merged. > 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)