Page History

...

The "resource_name" is the name of the particular resource.  For example, when "resource_type" == "topic", "resource_name" will be the topic name.  In the wire protocol, we represent principal as a NULLABLE_STRING.

...

DescribeAclsRequest and

...

DescribeAclsResponse

ListAclsRequest DescribeAclsRequest handles listing describing the ACLs in the cluster.  Principals must possess Cluster:Describe permissions to call ListAclsRequestDescribeAclsRequest, or be superuser.  Unauthorized requests will receive a ClusterAuthorizationException.

ListAclsRequestDescribeAclsRequest (Version: 0) => principal host operation permission_type resource_type resource_name
  principal => NULLABLE_STRING
  host => NULLABLE_STRING
  operation => INT8
  permission_type => INT8
  resource_type => INT8
  resource_name => NULLABLE_STRING

The arguments to ListAclsRequest DescribeAclsRequest are ANDed together to act as a filter.  For example, if a principal is supplied, we will return only ACLs that match that principal.  If an operation is supplied, we will return only ACLs that include that operation.  And so forth.  This capability can be used to easily list all the ACLs that apply to a particular topic, or a particular principal.

Note that an argument of "any" or null is different than a wildcard argument.  That is, ListAclsRequestDescribeAclsRequest(principal=null) will return all ACLs, but ListAclsRequestDescribeAclsRequest(principal=*) will return only ACLs that have their principal set to wildcard.

ListAclsResponseDescribeAclsResponse (Version: 0) => error_code error_message [resource]
  error_code => INT16
  error_message => NULLABLE_STRING
  resource => resource_type resource_name [acl]
    resource_type => INT8
    resource_name => STRING
    acl => principal host operation permission_type
      principal => STRING 
      host => STRING
      operation => INT8
      permission_type => INT8

The error_code field will be non-zero if there was an error processing the request.  If the error_code is non-zero, the results list will be empty.  Otherwise, each listed resource object describes a specific resource, and the ACLs bound to that resource.  Note that if filters were specified in the ListAclsRequestDescribeAclsRequest, this may not be a complete list of all the ACLs bound to the resource, but only the ones which matched the supplied filters.  None of the fields in the ACL 4-tuple or the resource 2-tuple are ever set to null or none in the response.

...

class AclFixture {
  AclResource resource;
  AclData data;
}

...

AdminClient#describeAcls

The listAcls API surfaces ListAclsRequest.

ListAclsResultDescribeAclsResult AdminClient#listAclsAdminClient#describeAcls(AclFixture filter, ListAclsOptionsDescribeAclsOptions options);

public ListAclsOptionsDescribeAclsOptions 
  ListAclsOptionsDescribeAclsOptions setTimeout(Integer timeout);
}

The "filter" object is a filter which will be used to select which ACLs are reported.  Fields which are null or ANY match anything.  It is an error to specify fields as UNKNOWN.

The ListAclsResult DescribeAclsResult object contains a KafkaFuture with the ACL Descriptions.

public ListAclsResultDescribeAclsResult {
  public KafkaFuture<List<AclFixture>> all();
}

...

What if we later add more dimensions to the 4-tuple that describes ACLs, or the 2-tuple that describes resources?  CreateAcls will continue to work, although the entries it creates will always get the default value for the new dimension.  ListAcls DescribeAcls and DeleteAcls will also continue to work.  The filters created by older clients will always have an implicit "any" entry for the new dimension.  This allows the old AdminClient to continue to be able to function in the new environment.

...