[
https://issues.apache.org/jira/browse/KAFKA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364166#comment-14364166
]
Parth Brahmbhatt commented on KAFKA-1688:
-----------------------------------------
[~jkreps][~junrao] Not sure if you guys had time to review
https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface
but I have to make a design choice and will appreciate your input.
As mentioned in the KIP, I originally thought we will just update TopicMetadata
class to hold the acls and owner which should allow us to reuse
TopicMetadataCache to get the acl information. However on further inspection I
realized that TopicMetadataCache is just serving as the cache for Topic's
partition state info and we have a completely different mechanism for caching
and updating topic config entries.
Currently the topic config is all about Log configuration so we have a
TopicConfigManager which takes in a Log instance and keeps updating that
instance's config instance as and when the topic config is updated. The topic
config update notifications are sent using zk watchers by Controller.
I propose to introduce a TopicConfigCache which will be updated by
TopicConfigManager on any config changes. Both the log instance and authorizer
will share an instance of TopicConfigCache to read the config entries from it.
The acls and owner of the topic will be stored as part of topic config.
An alternate solution is to modify the TopicMetadataCache so it also has topic
configs. The controller will have to send updateTopicMedataCache requests on
both partition changes and config changes. We will have to deprecate
TopicConfigManager and the controller code that updates zk state to fire config
change watchers.
I am currently blocked by this so I appreciate any feedback from you guys.
> Add authorization interface and naive implementation
> ----------------------------------------------------
>
> Key: KAFKA-1688
> URL: https://issues.apache.org/jira/browse/KAFKA-1688
> Project: Kafka
> Issue Type: Sub-task
> Components: security
> Reporter: Jay Kreps
> Assignee: Parth Brahmbhatt
> Fix For: 0.8.3
>
>
> Add a PermissionManager interface as described here:
> https://cwiki.apache.org/confluence/display/KAFKA/Security
> (possibly there is a better name?)
> Implement calls to the PermissionsManager in KafkaApis for the main requests
> (FetchRequest, ProduceRequest, etc). We will need to add a new error code and
> exception to the protocol to indicate "permission denied".
> Add a server configuration to give the class you want to instantiate that
> implements that interface. That class can define its own configuration
> properties from the main config file.
> Provide a simple implementation of this interface which just takes a user and
> ip whitelist and permits those in either of the whitelists to do anything,
> and denies all others.
> Rather than writing an integration test for this class we can probably just
> use this class for the TLS and SASL authentication testing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
