Page History

...

• What should be the default behavior for scenarios like "no configured acls" or "no authorizer configured even if user is using secure channels". Generally in secure setups the de-facto behavior is to fail close but for backward compatibility we may want to stick to fail open behavior. 

• Do we want to support authorization of KafkaAdminUtil operation? In absence of any alternative approach we are currently leaning to defer design and implementation for this to a future release after KIP-4 is merged into trunk.

• What does acls on zookeeper node look like given all our admin APIs are currently performed directly from client? Any plans of moving to curator? The current library uses zookeeper version 3.3 which was released in 2010 so its pretty old. Zookeeper did not add sasl support until version 4.0 so to use any sasl feature we will have to upgrade that library to a 4.X version.I have submitted a PR https://github.com/sgroschupf/zkclient/pull/31 but I think it is better to move to a more mature library like curator which is being actively maintained. 
• Do we want to support group acls as part of this authorizer? Do we want to support principal to local user mapping? If yes we need to add plugins for UserToGroupMapper and PrincipalToUserMapper.
•  

  The owner field of a topic in current proposal is set to the user who created the topic and this user has all access to the topic. There was suggestion on making this a list of users who can share ownership. alternatively we can keep the user as a single entity but the user creating the topic will have to ensure that the topic acls are configured to allow admin access to all the other users that wants to assume co-ownership.

Compatibility, Deprecation, and Migration Plan

...