Status

Current state: Under Discussion

Discussion thread: here

JIRA: KAFKA-3492

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

KIP-13 introduced client quotas in Kafka 0.9.0.0. Rate limits on producers and consumers are enforced to prevent clients saturating the network or monopolizing broker resources. The current implementation allocates quotas to client-ids. This works well in single user clusters or clusters that use PLAINTEXT where all users have the same identity. But since client-id is unauthenticated and can be set to any value by the client, multi-tenant secure installations require quotas to be enforced for authenticated principals to guarantee fair allocation of resources and prevent denial-of-service.

This KIP adds an option to apply quotas based on authenticated principal to prevent users generating heavy traffic from monopolizing resources and impacting the performance of other users in a multi-tenant cluster.

Public Interfaces

Configuration Options

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-principal based implementation.  The default value will be clients to be consistent with Kafka 0.9.0.x and 0.10.0.x.

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

Metrics

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

Tools

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

Proposed Changes

Authenticated Principal 

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.  

Quota Configuration

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

Quota Identifier

Quota configuration and metrics currently use client-id as the unique key, enforcing one quota for all clients with the same client-id. This will be replaced with a new quota-id. Each quota-id is associated with a pair of producer and consumer rate limits which may be config overrides or the default quota.  Quota id is set to either client-id or the encoded user principal based on the value of quota.type.

Quota Persistence in Zookeeper

Client-id based quotas will continue be stored under /config/clients. Authenticated user quotas 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.

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.

Compatibility, Deprecation, and Migration Plan

quota.type is 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 new secure quotas are not defined. If quota.type is set to user-principal and default or new quotas are configured for users, clients may be throttled based on the quota limits. But no client API changes are necessary to work with the new implementation.

Rejected Alternatives

Hierarchical quotas with configurable sub-quotas for clients of a user

It may be useful to allocate sub-quotas for clients of a user to enable a user to run multiple rate-limited clients. Since this adds complexity to the implementation and configuration and there are no requirements to support this feature at the moment, a simpler single-level user quota was preferred.