[jira] [Created] (KAFKA-12907) Cannot lockdown access to topic creation using Kafka ACLs

["Krishna Kinnal (Jira)" <ji...@apache.org>]

Krishna Kinnal created KAFKA-12907:
--------------------------------------

             Summary: Cannot lockdown access to topic creation using Kafka ACLs
                 Key: KAFKA-12907
                 URL: https://issues.apache.org/jira/browse/KAFKA-12907
             Project: Kafka
          Issue Type: Bug
          Components: admin, security
    Affects Versions: 2.6.1
            Reporter: Krishna Kinnal


We're using Apache Kafka 2.6.1 clusters.

 

We set a certain identity to have all privileges to a cluster by running this command:-
{noformat}
➜  bin/kafka-acls.sh --bootstrap-server kafka-cluster:9094 --command-config ../kafka-admin.properties --add --allow-principal User:CN=kafka-admin --operation All --cluster {noformat}
 

According to this page - [https://docs.confluent.io/platform/current/kafka/authorization.html#operations] - we figured that this would give only the "kafka-admin" identity the privilege to create/delete topics, and to create/delete ACLs, among other privileges. We noticed that most privileges like creating/deleting/describing ACLs, listing groups, etc., are locked down to this identity as expected, however topic creation is not. Meaning, any identity (that is not "kafka-admin") with a valid cert can still create topics.

 

This means that if a rogue client were to get hold of a cert with an identity that is not the admin identity, that client can create a topic and send terabytes worth of data to the topic to severely affect the cluster's performance, and with that, the other co-tenants' performance too. This is not an ideal scenario for us as Kafka admins since we would like to lockdown topic creation access only to identities with certificates that we possess. 

 

We're wondering if there's a workaround to this solution currently (like whether we're probably missing a config somewhere), or if this is an open issue that needs a fix.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)