...

Status

Current state: under discussionaccepted

Discussion thread: https://www.mail-archive.com/dev@kafka.apache.org/msg70858.html

JIRA:

Released: 0.11.0

Motivation

As part of the KIP-117 work to create an AdminClient for Kafka, we would like to have a way of adding, deleting, and listing the access control lists (ACLs) which are used to control access on Kafka topics and brokers.

...

• 0: unknown

• 1: any

• 2: topic

• 3: group

• 4: cluster

• 5: transactional_id

   

"Unknown" represents a resource type that we don't know how to decode.  "Any" can only be used in filters, and matches any resource type.

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

Each of the The arguments to ListAclsRequest acts 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.

...

CreateAclsRequest handles adding new ACLs in the cluster. Principals must possess Cluster:All Alter permissions to call CreateAclsRequest, or be superuser.  Unauthorized requests will receive a ClusterAuthorizationException.

...

There will be a creation_response for each creation in the CreateAclsRequest.  The responses will appear in the same order which the requests appeared.  For creations which completed successfully, error_code will be 0 and error_message will be null.  If there was an error, the error_code will be non-zero and the error_message will give a detailed error message describing why the creation could not be performed.

Because the arguments to CreateAclsRequest are concrete ACLs and not filters, they should not contain ANY or null fields.  They also should not contain UNKNOWN fields.  Resource names cannot be empty.  When the resource type is CLUSTER, the name must be "kafka-cluster".

DeleteAclsRequest and DeleteAclsResponse

DeleteAclsRequest handles removing ACLs.  Principals must possess Cluster:All Alter permissions to call DeleteAclsRequest, or be superuser.  Unauthorized requests will receive a ClusterAuthorizationException.

...

Filter responses will be appear in the same order which the filters appeared.  If the filter_response has a non-zero error_code, that means that the filter could not be applied by the server, and the match array will be empty.  Otherwise, the match array contains a list of all the ACLs that matched the filter.  Each match will have a non-zero error code and error message if it could not be removed.  When a filters fails to match an ACLs, it is not an error.  This will simply result in getting back a filter_response with an empty match list.

The arguments to DeleteAclsRequest should not contain UNKNOWN fields.  The UNKNOWN enum type is intended to represent a server response that can't be fully understood by the client, not a request which the client sends.  However, in a filter, ANY or null fields will match UNKNOWN fields.  So it is possible to construct a filter that will delete all ACLs attached to a particular topic, even when some of those ACLs contain UNKNOWNs.

If the client is newer than the broker, some of the fields may show up as UNKNOWN on the broker side.  In this case, the filter will get an UnsupportedVersionException and the filter will not be applied.

New AdminClient APIs

ResourceType, AclOperation, AclPermissionType

...

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();
}

...

Note that removing a topic does not remove the associated ACLs, nor does removing ACLs remove the associated topic.

New Exceptions

SecurityDisabledException

If no authorizer is configured, and the user attempts to list, add, or remove ACLs, SecurityDisabledException will be thrown.  Its error code will be 53.

Compatibility Plan

Since there are no existing ACL APIs and requests, backwards compatibility is not an issue.  However, we still need to think about forwards compatibility.  The version of the AdminClient that we release in 0.11 should be able to interact with future versions of the broker.

...

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.

...