Hi Kasper, > Starting with Kafka v3.8.0, methods like logAuditMessage and isSuperUser in AclAuthorizer were made private, which breaks our implementation. > 1. Is this change intentional, and if so, is there a recommended way to handle logging or superuser checks in custom authorizers? I checked the change history, I think this is intentional to mark methods and fields private where possible. To workaround this issue, you can write your own `isSuperUser` and `logAuditMessage` if needed, since all the data are retrievable.
> 2. With the move to KRaft, we noticed the StandardAuthorizer is used. Should we transition to this for KRaft environments, and does it provide equivalent functionality for custom logic? StandardAuthorizer has similar functionality for KRaft authorizer. You can check KIP-801 <https://cwiki.apache.org/confluence/display/KAFKA/KIP-801%3A+Implement+an+Authorizer+that+stores+metadata+in+__cluster_metadata> for more information. Thanks. Luke On Fri, Jan 10, 2025 at 5:37 AM Kasper Andersen Storgaard <k...@trifork.com.invalid> wrote: > Hi, > > > We’re upgrading from Kafka v3.7.1 to v3.9.0 and encountered issues with > our custom Kafka Authorizer that extends AclAuthorizer. Starting with Kafka > v3.8.0, methods like logAuditMessage and isSuperUser in AclAuthorizer were > made private, which breaks our implementation. > > 1. Is this change intentional, and if so, is there a recommended way to > handle logging or superuser checks in custom authorizers? > > 2. With the move to KRaft, we noticed the StandardAuthorizer is used. > Should we transition to this for KRaft environments, and does it provide > equivalent functionality for custom logic? > > > Any guidance would be greatly appreciated! > > > Best regards, > > Kasper >
