I think that if this is introduced (and perhaps even if it is not) we need a clear ACL evaluation process.
I know we have both allow and deny, and that deny takes precedence over allow. But let's consider two scenarios 1. Unintended access. Let's assume we start with the 6 topics Murali used in his example: nl-accounts-localtopic, nl-accounts-remotetopic, de-accounts-localtopic, de-accounts-remotetopic, cz-accounts-localtopic, and cz-accounts-remotetopic Assume that *-accounts-* pattern granted read access to anyone. I create an account us-accounts-privatetopic and grant explicit access some individuals. Because of the *-accounts-* everyone has access to my privatetopic, and I may not know that there is a leak until it is far too late. I don't have a good way to determine which ACLs will impact my topic. I cannot add a general us-accounts-privatetopic DENY and hope my explicit access works because DENY takes precedence over ALLOW. 2. Unintended/Hostile denial Let's assume we start with the 6 topics Murali used in his example: nl-accounts-localtopic, nl-accounts-remotetopic, de-accounts-localtopic, de-accounts-remotetopic, cz-accounts-localtopic, and cz-accounts-remotetopic Assume that *-accounts-* pattern grants read access to anyone. A bad or carless actor could create *-* DENY which would cause the system to cease functioning as expected. There is not a good way to determine which ACLs impacted the topic. *Note* that both of these issues can occur with the PREFIXED pattern as well, so this is not an argument against the MATCH pattern. There is a fundamental issue with the current ACL implementation as relates to wildcards. I think that the evaluation process should be: 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 generally 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. *Usability* With the ACL system becoming a complex web of patterns, it is incumbent upon the development team to provide tools to assist in permissions problem determination. 1. There should be a tool that will provide a list of all ACLs that impact the decision to allow or deny access for a principal to a topic based on principal ID, host, and operation. This will assist operators in rapidly determining the reason for access denied errors. 2. There should be a tool to show the effects of adding an ACL. Using the example from above adding *-accounts-*", should list that nl-accounts-localtopic, nl-accounts-remotetopic, de-accounts-localtopic, de-accounts-remotetopic, cz-accounts-localtopic, and cz-accounts-remotetopic are affected. 3. There should be a tool to show the effects of adding a topic. Using the example from above adding *us-accounts-privatetopic", should list that "*-accounts-*" will influence the permissions calculations for the new topic. *Summary* I leave determining whether or not adding MATCH as a pattern type is a good idea to others with more experience in Kafka. But in either case, I believe that we need to look at how we evaluate ACLs given that we already have a wild card ACL pattern. Claude On Thu, May 2, 2024 at 3:56 PM 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 >
