Page History

...

We extend the same storage model to store ACLs under wildcard-suffixed resource names like orgName* new ACLs in a different location 'kafka-wildcardacl-aclv2'. Changes will first be stored at 'kafka-wildcardacl-aclv2-changes'.

$ get /kafka-wildcardacl-aclv2/Topic/teamA*
{"version":1,"acls":[{"principal":"User:clientA","permissionType":"Allow","operation":"Read","host":"*"}]}

ACLs write path

Write to a new location 'kafka-wildcardacl-aclv2'.

$ get /kafka-wildcardacl-aclv2/Topic/orgName*
{"version":1,"acls":[{"principal":"User:clientA","permissionType":"Allow","operation":"Read","host":"*"}]}

ACLs read path

On read path, we look for all matching ACLs when:

a) getMatchingAcls(resourceWithWildcardSuffix) is called.
b) authorize(…) is called.

Access would be allowed if there is at least one ALLOW matching acl and no DENY matching acl (current behavior is maintained). Note that the length of the prefix doesn't play any role here.

...