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

Reply via email to