...

• What should be the default behavior for scenarios like "no acls found" which will be the case for all topics created before security release? Generally in secure setups the de-facto behavior is to fail close but this forces users to add an "Allow everyone from all hosts" acl to all of their existing topics. 
  • We agreed on default behavior as "Deny all" when no acls found. In addition to avoid extra configuration we will add another config override flag "allow.access.to.topic.with.no.acls" <I am too verbose>. If users set this value to true the default behavior will change to allow all when no acls are found.
• What should be the storage for out of box Authorizer implementation? Zookeeper seems like a good fit here as acls seldom change and we can have a caching layer with TTL of 1 hour. Jun has suggested to use topic (just like we use it for consumer offset storage) which will allow mirror maker to replicate acls without any changes however this means for any custom authorizer the acls will not be replicated by mirror maker. It might be better to update mirror maker to explicitly use getAcls and addAcls API so Acls are replicated no matter what authorizer implementation is chosen.authorizer implementation is chosen.
  • We agreed on zookeeper as storage with an optimization where we will introduce a notification flag that will be watched by all brokers any it will be used to notify all brokers that they should update their cacheon acl change. 
• Do we want to modify the existing CLI with all the acl options? or just create a new acl management CLI? 
  • We agreed that we will create a new CLI tool. 
• Do we want to support Deny as a permissionType? This adds support for complex acls like "allow access to user1 from all hosts but host1,host2" at the expense of simplicity. I don't think anyone feels about keeping/removing this strongly so will be great to make a quick decision. 
  • We agreed to support Deny to support a wider set of usecases.
• Do we want 1:1 mapping from Operation to API or a categorization as listed above? If we decide to go with a 1:1 mapping I think it is better to make it an open string instead of an enum.
  • We agreed to go with categorization approach.
•  Should we even allow defining acls for operation type CLUSTER_ACTION or only allow super users to perform these actions? 
  • CLUSTER_ACTIONs will only be allowed by super users and setting acls will have no effect in default implementation.

Compatibility, Deprecation, and Migration Plan

...