Resolution: Won't Fix
Affects Version/s: 0.9.0.0
Fix Version/s: 0.10.0.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.