Page History

...

We will introduce 2 new ACL operations: ReadConfigs DescribeConfigs and WriteConfigsAlterConfigs. These operations apply to resources that have configs (i.e. Broker and Topic). In addition, ReadConfigsDescribeConfigs/WriteConfigs AlterConfigs on the Cluster resource allows one to read and write configs on any resource with configs. Finally, the ReadConfigs DescribeConfigs and WriteConfigs AlterConfigs operations are included in the `All` operation.

...

• 0: Unknown

• 1: Any

• 2: All

• 3: Read

• 4: Write

• 5: Create

• 6: Delete

• 7: Alter

• 8: Describe

• 9: ClusterAction

• 10: ReadConfigsDescribeConfigs (new)

• 11: WriteConfigsAlterConfigs (new)

ResourceType

• 0: Unknown

• 1: Any

• 2: Topic

• 3: Group

• 4: Cluster

• 5: Broker (new)

...

1. Can be sent to any broker
2. If there are multiple instructions for the same resource in one request, an InvalidRequestException will be logged on the broker and a single error code for that topic will be returned to the client
   • This is because the list of resources is modeled server side as a map with the resource as the key
3. Valid resource types are "Topic" and "Broker". However, since all broker configs are currently read_only, only the former makes sense until that changes.
4. If an Alter operation is attempted on a read-only config, an UnsupportedOperation error will be returned for the relevant resource.
5. Authorization is as follows:
   1. Topic configs: "WriteConfigsAlterConfigs" on the "Topic" or "Cluster" resource ("WriteConfigsAlterConfigs" is also included in the "All" operation). Unauthorized requests will receive an appropriate AuthorizationFailed error code.
   2. Broker configs: "WriteConfigsAlterConfigs" on the "Broker" or "Cluster" resource ("WriteConfigsAlterConfigs" is also included in the "All" operation). Unauthorized requests will receive an appropriate AuthorizationFailed error code.
6. Replication, User and Client Quota configs are not supported. See "Future work" for more details.
7. The request is not transactional. 
   1. If an error occurs for an resource, others could still be updated.
   2. Errors are reported independently per resource.
8. For tools that allow users to alter configs, a validation/dry-run mode where validation errors are reported but no creation is attempted is available via the validate_only parameter.

...

1. Allowing sensitive data to be returned: it's good security practice to never expose sensitive data. If necessary, the user can reset the relevant sensitive data (e.g. a password).
2. Introducing a new Configs resource instead of ReadConfigs DescribeConfigs and WriteConfigs AlterConfigs operations: there is always a one to one mapping between a resource and its configs, so there isn't much value in creating a separate resource for Configs. By adding new operations to existing resources, it's easier to see all the ACLs that affect a given resource.

...

1. Forward requests to the relevant brokers in order to return `read-only` broker configs.More fine-grained ACLs so that a user authorized to ReadConfigs/WriteConfigs on a given resource type (topic, broker , etc.) can read/write the relevant configs.
2. Support for reading and updating client, user and replication quotas. We initially included that in the KIP, but it subsequently became apparent that a separate protocol and AdminClient API would be more appropriate. The reason is that client/user quotas can be applied on a client id, user or (client id, user) tuple. In the future, the hierarchy may get even more complicated. So, it makes sense to keeping the API simple for the simple cases while introducing a more sophisticated API for the more complex case.