I have 2 suggestions:
1) We need to document how does one move from secure to non secure
environment:
1) change the config on all brokers to zookeeper.set.acl = false and do
a
rolling upgrade.
2) Run the migration script with the jass config file so it is sasl
authenticated with zookeeper and change the acls on all subtrees back to
World modifiable.
3) remove the jaas config / or only the zookeeper section from the jaas,
and restart all brokers.
2) I am not sure if we should force users trying to move from unsecure to
secure environment to execute the migration script. In the second step
once the zookeeper.set.acl is set to true, we can secure all the subtrees
by calling ensureCorrectAcls as part of broker initialization (just after
makesurePersistentPathExists). Not sure why we want to add one more
manual/admin step when it can be automated. This also has the added
advantage that migration script will not have to take a flag as input to
figure out if it should set the acls to secure or unsecure given it will
always be used to move from secure to unsecure.
Given we are assuming all the information in zookeeper is world readable ,
I don¹t see SSL support as a must have or a blocker for this KIP.
Thanks
Parth
On 10/21/15, 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/util
>s/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
>>>
>
