[
https://issues.apache.org/jira/browse/KAFKA-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152812#comment-15152812
]
ASF GitHub Bot commented on KAFKA-3221:
---------------------------------------
Github user SinghAsDev closed the pull request at:
https://github.com/apache/kafka/pull/895
> kafka-acls.sh must verify if a user has sufficient privileges to perform acls
> CRUD
> ----------------------------------------------------------------------------------
>
> Key: KAFKA-3221
> URL: https://issues.apache.org/jira/browse/KAFKA-3221
> Project: Kafka
> Issue Type: Improvement
> Affects Versions: 0.9.0.0
> Reporter: Ashish K Singh
> Assignee: Ashish K Singh
> Fix For: 0.9.1.0
>
>
> kafka-acls.sh provides an insecure entry point to Kafka's authorization. No
> checks are performed or no user information is provided to authorizer to
> validate a user, before the user performs CRUD of acls. This is a security
> hole that must be addressed.
> As Kafka supports pluggable authorization, we need to look at this issue from
> two aspects.
> 1. Default zk based authorizer, SimpleAclAuthorizer
> For SimpleAclAuthorizer, one could rely on Zookeeper authentication to check
> if a user can really perform CRUD on Kafka acls. However, this check relies
> on the assumption, which is usually true, that non-admin users won't have
> access to Kafka service's user account.
> 2. Custom Authorizer
> Custom authorizer that gets executed in same address space as of Kafka
> broker, does not have any way of determining which user is really trying to
> perform CRUD of acls. For authorize requests, authorizer gets user
> information, KafkaPrincipal, from session, however for CRUD of acls, i.e.,
> addAcls, removeAcls and getAcls, authorizer does not have requestor's info to
> validate if it should allow or deny the request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
