[
https://issues.apache.org/jira/browse/KAFKA-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140234#comment-15140234
]
ASF GitHub Bot commented on KAFKA-3221:
---------------------------------------
GitHub user SinghAsDev opened a pull request:
https://github.com/apache/kafka/pull/895
KAFKA-3221: Pass requesting user information to authorizer to enable …
…user authorization before modifying acls.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/SinghAsDev/kafka KAFKA-3221
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/kafka/pull/895.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #895
----
commit 0378232be9997be41c6417131549863bd7a972c6
Author: Ashish Singh <asi...@cloudera.com>
Date: 2016-02-10T02:46:02Z
KAFKA-3221: Pass requesting user information to authorizer to enable user
authorization before modifying acls.
----
> 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.0.1
>
>
> 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)
