...

The proposed change is to create a new ACL operation called AUTO_CREATE that will be checked to see if a user is authorized to auto create topics instead of using the existing CREATE operation. This new operation will apply both cluster wide (allowed to create a topic of any name) or topic wide (will validate by topic name or prefix). The CREATE operation will still be used for the existing CreateTopicsRequest command. Going forward this will allow an administrator to grant permission to auto create topics with cluster defaults but not to explicitly create topics.

The goals of this change:

1. Allow admins or super users the ability to create topics and also set explicit configs on the new topics.
2. Allow some users the ability to auto-create topics but not set explicit configs (only given cluster defaults).
3. Deny creation of topics entirely to other users.

Compatibility, Deprecation, and Migration Plan

...

The API could be changed such that CreateTopicPolicy (and also AlterConfigPolicy) could have the principal passed as part of the validation request. This could possibly work but is much more limited and I think using the built in ACL mechanism that already exists seems like a better solution as this is really a permission issue that is trying to be solved. However, this approach could be used instead of if the community wants to go this routeWhile passing the principal to the policy gives the policy the ability to know who is making the request, only the ACL authorizer has all the information loaded to make permissions decisions and that still wouldn't be available to the create topic policy. Without the ACL authorizer the best you could do would be just check if a super user which is better but still doesn't solve the whole problem if you want to grant non super users the ability to create topics explicitly for certain topic prefixes.