[
https://issues.apache.org/jira/browse/KAFKA-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish K Singh updated KAFKA-3221:
----------------------------------
Description:
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.
was: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.
> 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
>
> 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)
