kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Kafka Authorizer interface review
Date Tue, 03 Apr 2018 16:26:46 GMT
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 ?


On Tue, Apr 3, 2018 at 9:22 AM, Mickael Maison <mickael.maison@gmail.com>

> 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

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