...

• We will add a new method getMatchingAcls(resource) to the Authorizer interface.

  • The behavior of getAcls(resource) method today is to return ACLs matching only the resource literal.
  • authorize(...) method calls getAcls(resource) and getAcls('*') to get all the matching ACLs today.
  • If I want to fetch all ACLs that match ’topicA*’, it’s not possible without introducing new API AND maintaining backwards compatibility.
  • (Question) Should we deprecate getAcls(resource) method then? Not at this point?
    
    

  Code Block
  language scala title Authorizer
  /** * Get set of all acls that match this resource. * @param resource regular or wildcard-suffixed resource name. * @return empty set if no acls are found, otherwise the acls for the matching resources. */ def getMatchingAcls(resource: Resource): Set[Acl]

  OR

  • Enhance getAcls(resource) to return all matching wildcard-suffixed ACLs (breaking change and lot of unit tests need to be modified)

• Changes to command line tool class https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/admin/AclCommand.scala
  • To expose the above new API (if we go that route).
  • Expose a '--wildcard-suffix-resource' flag which is "false" by default to maintain backwards compatibility (though "true" is more user friendly going forward)
    • bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181
      --add --allow-principal User:Bob --allow-principal User:Alice --allow-host
      198.51.100.0 --allow-host 198.51.100.1 --operation Read --group my-app-* –wildcard-suffix-resource true
• Add new field 'ResourceNameType' to Resource and ResourceFilter classes, which would define if the resource name is a literal or wildcard-suffix (ResourceNameType is an enum to support more types in the future)
• Changes to AdminClient
  • Add a new method that will allow users to escape resource names for using special characters (@, #, $, %, ^, &, *, /, +)
  (Question) Should we deprecate older getAcls(resource) method? Not at this point?- None.
• New API keys for CreateAclsRequest / DeleteAclsRequest / DescribeAclsRequest which would have a new field in schema to distinguish literals vs wildcard-suffix resource names.
• Update the public documentation with the details of the new feature.

...

On downgrade, the wildcard ACLs will be treated as literals and hence never match anything. This means that any wildcard ACLs would be treated as if they were never added. This is fine for ALLOW ACLs, but might have security implications if DENY ACLs are ignored.

Rejected Alternatives

• Use escaping to identify wildcard-suffix vs literals (won't work on ZK). We decided to use a separate path for wildcard-suffix ACLs