bq. There is now way to distinguish between topic and record deletion. I guess you meant 'no way' above. I think deleting a topic has higher impact than deleting records.
Have you considered filing KIP to distinguish the two operations ? Cheers On Tue, Apr 3, 2018 at 9:22 AM, Mickael Maison <mickael.mai...@gmail.com> wrote: > Hi all, > > Over the past few months the IBM Message Hub team has "played quite a > bit" with the pluggable Authorizer interface and I'll try to give a > summary of our findings. > > First when implementing a custom Authorizer, we found it hard having a > global view of all the Resource/Operation required for each ApiKey. We > ended up building a table (by looking at KafkaApis.scala) of all the > combinations that can be triggered. We posted this table in the wiki, > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorizations, > hopefully that will help others too. > > We found the overview it provides necessary and it should probably be > in the docs/javadocs. > > The biggest limitation for us were the permissions required to create > topics. This is what we targeted with KIP-277: > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 277+-+Fine+Grained+ACL+for+CreateTopics+API > > Some of our other findings: > - There is now way to distinguish between topic and record deletion. > If a Principal has Delete on a Topic, it can do both. With regulations > like GDPR, we can expect the DeleteRecords API to gain popularity and > it's a bit scary that it also allows to delete the topic. > - We also can't distinguish between DescribeLogDirs, DescribeAcls and > ListGroups as they both require Describe on the Cluster resource. > While ListGroups is pretty common for "normal" users, the other 2 are > a bit more on the admin side. > - OffsetCommit only requires Read on Group even though it's > technically a write operation. I think this was already discussed at > some point on the mailing list. > > Changing permissions is an expensive process and so far we've not > attempted to come up with alternatives (apart from KIP-277). There is > also a balance between granularity and ease of use, requiring > administrators to set and maintain many permissions is not really an > improvement! > > Thanks >
