> On 21 Oct 2015, at 18:07, Parth Brahmbhatt <pbrahmbh...@hortonworks.com> > wrote: > > 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. >
Thanks for bringing it up, it makes sense to have a downgrade path and document it. > 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. > The advantage of the third step is to make a single traversal to change any remaining znodes with the open ACL. As you suggest, each broker would do it, so the overhead is much higher. I do agree that eliminating a step is an advantage, though. > 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. OK, but keep in mind that SSL is only available in the 3.5 branch of ZK. -Flavio > > 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 >>>> >> >
