[
https://issues.apache.org/jira/browse/KAFKA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14378064#comment-14378064
]
Parth Brahmbhatt commented on KAFKA-1688:
-----------------------------------------
[~prasadm] Thanks for taking the time to review.
* Personally, I don't like super user concept primarily because even though it
provides convenience it also increases the blast radius of the entire system.
If a user's credentials are compromised in the current design only topics and
actions he can perform on a cluster are compromised. However I think its fair
to provide this feature so the users can make that choice on their own. I will
update the KIP to reflect this as part of the proposal and let others vote for
it.
The user's won't have to grant permissions on non existing topics in absence of
the super user concept. However they will have to supply permissions during
topic creation and they will be allowed to alter these ACLs via alter topic
command line tool.
* I can add ALL as an item to the Operation enum. For now, like most other
permissions it will only be applicable to topics.
> 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)
