kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vahid S Hashemian" <vahidhashem...@us.ibm.com>
Subject Re: Kafka Authorizer interface review
Date Tue, 03 Apr 2018 17:41:26 GMT
Hi Mickael,

Thanks for detailed description on these authorization issues.
I agree they need to be reviewed and fixed in the areas you specified, or 
even at a higher that simplifies their maintenance as the matrix is 
expanded or needs to be modified.
FYI, KIP-231 also attempts at addressing the issue with ListGroups API in 
a backward compatible way.


From:   Mickael Maison <mickael.maison@gmail.com>
To:     dev <dev@kafka.apache.org>
Date:   04/03/2018 09:22 AM
Subject:        Kafka Authorizer interface review

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,
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:

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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message