Hi Gwen - I tend to agree with your proposal. As you mention the exact details / interfaces would need to be worked out, but this would be more in line with how JAAS and JACC work in the Java / JEE worlds.
I do think that it might be nice to include / provide some "helper" APIs / methods for caching (so that people don't accidentally cause OOM situations) and it would be convenient to have some type of distribution / synchronization mechanisms for local / file based ACL lists (again perhaps it would be possible to provide a standard helper method for using Zookeeper?). -- Gari On Thu, Apr 16, 2015 at 11:44 AM, Gwen Shapira <gshap...@cloudera.com> wrote: > Hi Kafka Authorization Fans, > > I'm starting a new thread on a specific sub-topic of KIP-11, since > this is a bit long :) > > Currently KIP-11, as I understand it, proposes: > * Authorizers are pluggable, with Kafka providing DefaultAuthorizer. > * Kafka tools allow adding / managing ACLs. > * Those ACLs are stored in ZK and cached in a new TopicCache > * Authorizers can either use the ACLs defined and stored in Kafka, or > define and use their own. > > I am concerned of two possible issues with this design: > 1. Separation of concerns - only authorizers should worry about ACLs, > and therefore the less code for ACLs that exist in Kafka core, the > better. > 2. User confusion - It sounded like we can define ACLs in Kafka itself > but authorizers can also define their own, so "kafka-topics > --describe" may show an ACL different than the one in use. This can be > super confusing for admins. > > My alternative suggestion: > * Authorizer API will include: > grantPrivilege(List<Principals>, List<Privilege>) > revokePrivilege(List<Principals>, List<Privilege>), > getPrivilegesByPrincipal(Principal, Resource) > .... > (The exact API can be discussed in detail, but you get the idea) > * Kafka tools will simply invoke these APIs when topics are added / > modified / described. > * Each authorizer (including the default one) will be responsible for > storing, caching and using those ACLs. > > This way, we keep almost all ACL code with the Authorizer, where it > belongs and users get a nice unified interface that reflects what is > actually getting used in the system. > This is pretty much how Sqoop and Hive implement their authorization APIs. > > What do you think? > > Gwen >
