Page History

...

• Principal “com.company.product1.client” has access to all topics that start with “com.company.product1.”.
• Principal “com.company.client1” has access to all consumer groups that start with “com.company.client1.”.

This support would will greatly simplify ACL operational story in a multi-tenant environment.

...

• Enhance implementation of getAcls(resource) in SimpleAclAuthorizer to return all matching wildcard-suffixed ACLs if 'ResourceNameType' in input resource is a wildcard-suffix.
  • 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.
  • Backward compatibility would will be maintained because 'ResourceNameType' defaults to literal.

• Changes to command line tool class https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/admin/AclCommand.scala
  • Expose a '--wildcard-suffixed-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-suffixed-resource true
  Changes to AdminClient - None.
• New API keys schema version for CreateAclsRequest / DeleteAclsRequest / DescribeAclsRequest which would will have a new field in schema schemas to distinguish literals vs wildcard-suffix resource names.
• Update the public documentation with the details of the new feature.

...

Solution

The proposal is to extend the concept of wildcard ACL (‘*’) to support wildcard-suffixed ACLs (‘name*’).
This means that it would will be possible to create ACLs of type: User:clientA has READ access on topic orgA* from hostA,
i.e clientA has READ access to all topics that start with `orgA` from hostA.
The concept of wildcard-suffixed ACLs would will be applicable only to resource names.

Storage model

Currently, ACLs are stored on ZK under path /kafka-acl/<resource-type>/<resource-name>.

For example:
ACLs for topic topicName would will be stored under /kafka-acl/Topic/topicName.
ACLs for consumer group groupId would will be stored under /kafka-acl/Group/groupId.

An example ACL definition looks like:

$ get /kafka-acl/Topic/topicName
{"version":1,"acls":[{"principal":"User:clientA","permissionType":"Allow","operation":"Read","host":"*"},{"principal":"User:clientA","permissionType":"Allow","operation":"Write","host":"*"},{"principal":"clientB","permissionType":"Allow","operation":"Write","host":"host1"}]}

Current supported resource names are either full resource names like topicName or a special wildcard '*'.

$ get /kafka-acl/Topic/*
{"version":1,"acls":[{"principal":"User:clientA","permissionType":"Allow","operation":"Read","host":"*"}]}
which means that clientA has read access to all topics from all hosts.

...

$ get /kafka-wildcard-acl/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 will 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.

...

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

...