Yeah let's definitely get a complete description of the user-facing impact, especially the changes to the command-line tools. As much as anything the purpose of these KIPs is to fully capture what the user's life will be like in the next release.
Also, if I understand correctly we aren't securing the consumer subtree so it will be possible to run the scala consumer (or other non-secure consumer) against a secured ZK cluster? -Jay On Wed, Oct 21, 2015 at 9:56 AM, Flavio Junqueira <f...@apache.org> wrote: > > > On 21 Oct 2015, at 17:47, Todd Palino <tpal...@gmail.com> wrote: > > > > There seems to be a bit of detail lacking in the KIP. Specifically, I'd > > like to understand: > > > > 1) What znodes are the brokers going to secure? Is this configurable? > How? > > Currently it is securing all paths here except the consumers one: > > > https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/utils/ZkUtils.scala#L56 > < > https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/utils/ZkUtils.scala#L56 > > > > This isn't configurable at the moment. > > > 2) What ACL is the broker going to apply? Is this configurable? > > The default is CREATOR_ALL_ACL + READ_ACL_UNSAFE, which means that an > authenticated client can manipulate secured znodes and everyone can read > znodes. The API of ZkUtils accommodates other ACLs, but the current code is > using the default. > > > 3) How will the admin tools (such as preferred replica election and > > partition reassignment) interact with this? > > > > Currently, you need to set a system property passing the login config file > to be able to authenticate the client and perform writes to ZK. > > -Flavio > > > -Todd > > > > > > On Wed, Oct 21, 2015 at 9:16 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > >> On Wed, Oct 21, 2015 at 5:04 PM, Flavio Junqueira <f...@apache.org> > wrote: > >> > >>> Bringing the points Grant brought to this thread: > >>> > >>>> Is it worth mentioning the follow up steps that were discussed in the > >> KIP > >>>> call in this KIP document? Some of them were: > >>>> > >>>> - Adding SSL support for Zookeeper > >>>> - Removing the "world readable" assumption > >>>> > >>> > >>> Grant, how would you do it? I see three options: > >>> > >>> 1- Add to the existing KIP, but then the functionality we should be > >>> checking in soon won't include it, so the KIP will remain incomplete > >>> > >> > >> A "Future work" section would make sense to me, but I don't know how > this > >> is normally handled. > >> > >> Ismael > >> > >
