Hi, Murali. First, could you add the KIP-1042 to the index ( https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals) as well so that everyone can find it easily?
I took a look at the KIP, then I have 2 questions: 1. Though the new MATCH resource pattern type may reduce the effort of adding ACLs in some cases, do you have any concrete use case you are in mind? (When prefixed ACL was introduced in KIP-290, there was a use-case that using it for implementing multi-tenancy) 2. As you may know, ACL lookup is in the hot-path which the performance is very important. ( https://github.com/apache/kafka/blob/240243b91d69c2b65b5e456065fdcce90c121b04/core/src/main/scala/kafka/security/authorizer/AclAuthorizer.scala#L539). Do you have ideas how do we update `matchingAcls` to support MATCH-type ACL without introducing performance issue? Thanks, 2024年5月3日(金) 19:51 Claude Warren, Jr <claude.war...@aiven.io.invalid>: > As I wrote in [1], the ACL evaluation algorithm needs to be specified with > respect to the specificity of the pattern so that we know exactly which if > *-accounts-* takes precedence over nl-accounts-* or visa versa. > > I think that we should spell out that precedence is evaluated as follows: > > 1. Remove patterns that do not match > 2. More specific patterns take precedence over less specific patterns > 3. for patterns of the same precedence DENY overrides ALLOW > > Determining specificity: > > Specificity is based on the Levenshtein distance between the pattern and > the text being evaluated. The lower the distance the more specific the > rule. > Using the topic name: nl-accounts-localtopic we can evaluate the > Levenshtein distance for various patterns. > nl-accounts-localtopic = 0 > *-accounts-localtopic = 2 > nl-accounts-local* = 5 > *-accounts-local* = 7 > nl-accounts-* = 10 > *-accounts-* = 12 > > In the special case of matching principles User matches are more specific > than Group matches. > > I don't know if this should be added to KIP-1042 or presented as a new KIP. > > Claude > > [1] https://lists.apache.org/thread/0l88tkbxq3ol9rnx0ljnmswj5y6pho1f > < > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1042%3A+Support+for+wildcard+when+creating+new+acls > > > > On Fri, May 3, 2024 at 12:18 PM Claude Warren <cla...@xenei.com> wrote: > > > Took me awhile to find it but the link to the KIP is > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1042%3A+Support+for+wildcard+when+creating+new+acls > > > > On Fri, May 3, 2024 at 10:13 AM Murali Basani <murali.bas...@gmail.com> > > wrote: > > > > > Hello, > > > > > > I'd like to propose a suggestion to our resource patterns in Kafka > ACLs. > > > > > > Currently, when adding new ACLs in Kafka, we have two types of resource > > > patterns for topics: > > > > > > - LITERAL > > > - PREFIXED > > > > > > However, when it comes to listing or removing ACLs, we have a couple > more > > > options: > > > > > > - MATCH > > > - ANY (will match any pattern type) > > > > > > > > > If we can extend creating acls as well with 'MATCH' pattern type, it > > would > > > be very beneficial. Even though this kind of acl should be created with > > > utmost care, it will help organizations streamline their ACL management > > > processes. > > > > > > Example scenarios : > > > > > > Let's say we need to create ACLs for the following six topics: > > > nl-accounts-localtopic, nl-accounts-remotetopic, > de-accounts-localtopic, > > > de-accounts-remotetopic, cz-accounts-localtopic, > cz-accounts-remotetopic > > > > > > Currently, we achieve this using existing functionality by creating > three > > > prefixed ACLs as shown below: > > > > > > kafka-acls --bootstrap-server localhost:9092 \ > > > > --add \ > > > > --allow-principal > > > > > > > > > > User:CN=serviceuser,OU=ServiceUsers,O=Unknown,L=Unknown,ST=Unknown,C=Unknown > > > > \ > > > > --producer \ > > > > --topic nl-accounts- \ > > > > --resource-pattern-type prefixed > > > > > > > > > kafka-acls --bootstrap-server localhost:9092 \ > > > > --add \ > > > > --allow-principal > > > > > > > > > > User:CN=serviceuser,OU=ServiceUsers,O=Unknown,L=Unknown,ST=Unknown,C=Unknown > > > > \ > > > > --producer \ > > > > --topic de-accounts- \ > > > > --resource-pattern-type prefixed > > > > > > > > > kafka-acls --bootstrap-server localhost:9092 \ > > > > --add \ > > > > --allow-principal > > > > > > > > > > User:CN=serviceuser,OU=ServiceUsers,O=Unknown,L=Unknown,ST=Unknown,C=Unknown > > > > \ > > > > --producer \ > > > > --topic cz-accounts- \ > > > > --resource-pattern-type prefixed > > > > > > > > > However, if we had the 'MATCH' pattern type available, we could > > accomplish > > > this with a single ACL, as illustrated here: > > > > > > kafka-acls --bootstrap-server localhost:9092 \ > > > > --add \ > > > > --allow-principal > > > > > > > > > > User:CN=serviceuser,OU=ServiceUsers,O=Unknown,L=Unknown,ST=Unknown,C=Unknown > > > > \ > > > > --producer \ > > > > --topic *-accounts-* \ > > > > --resource-pattern-type match > > > > > > > > > > > > This pattern closely resembles PREFIXED but offers broader allow/deny > > > rules. > > > > > > Implementing this change could significantly reduce the effort in > several > > > acl management processes. > > > > > > I welcome your thoughts and any concerns you may have regarding this > > > proposal. > > > > > > Thanks, > > > Murali > > > > > > > > > -- > > LinkedIn: http://www.linkedin.com/in/claudewarren > > > -- ======================== Okada Haruki ocadar...@gmail.com ========================
