Page History

...

A configuration option quota.type will be added with supported values "client-id" and "user-principal". This option can be used to choose between the existing client-id based implementation and the new authenticated user principal based implementation.  The default value will be client-id to be consistent with Kafka 0.9.0.x and 0.10.0.x.

Default quota configs will apply to user principals if quota.type=user-principal.

Metrics

If quota.type=user-principal, quota related metrics will be generated for user principals rather than client-ids.

Metric names currently use the tag client-id. The tag user will be set instead when quota.type=user. This makes the metrics tag name identical to quota.type and leaves existing metrics for client-ids unchanged.

Sensor names are currently a sensor type concatenated with the client id value, eg. FetchThrottleTime-clientA. This will be modified to include quota type using the format sensor.type-quota.type-quota.id. For example sensor name  FetchThrottleTime-client-id-clientA will be the throttle time sensor for clientA when quota.type=client-id and FetchThrottleTime-user-user1 will be the throttle time sensor for user1 when quota.type=user. Since sensor names are not reflected in JMX names, the change in sensor names for client ids will not impact externally visible metrics.

Tools

kafka-configs.sh will be extended to support quota overrides for user principals.  A new entity type “users” will be added which provides quota configuration similar to the existing entity type "clients".

...

Authenticated user principal will be obtained from the Session object when quota.type=user-principal. Base64-encoded hex string version of the Principal will be used so that it can be used as a node name in Zookeeper and as the metric name without placing any restrictions on the characters allowed in the principal.  For PLAINTEXT, the principal is "anonymous" by default and quotas will be applied for that principal. But principal can be overridden using a custom principal builder even for PLAINTEXT, enabling different user quotas, for example, for connections from different IP addresses.

...

Quotas are currently configured as the rate limits for producers and consumers based on their client-id. The same set of limits will be configurable for user principals. If quota.type=user-principal, the configuration specified for user principals will be used. Default options will applied to either client-id or user principal based on the value of quota.type.

...

Client-id based quota configuration overrides will continue be stored under /config/clients. Quota configuration overrides for user principals will be stored under /config/users. Only one of these will be processed and watched by the brokers depending on the value of quota.type. Note that Base64-encoded hex version of the user principal will be used as node name under /config/users to cope with Zookeeper naming restrictions. The non-encoded user principal with be stored as a property to make it easy to identify the actual user associated with the path.

Tools

kafka-configs.sh will be extended to support a new entity type "users". Configuration format for users will be the same as for the existing clients entity, but the entity will be stored in Zookeeper under /users.

...

quota.typeis set to  client-id as default to be consistent with Kafka 0.9.0.x and 0.10.0.x. Hence the existing quota configurations will apply. If quota.type is set to user-principal in broker configuration and default or new quotas are configured for users, clients may be throttled based on the quota limits for user principals. But no client API changes are necessary to work with the new implementation.

...