You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

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 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.

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

Metrics

When 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 when quota.type=users. 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 with default quotas for clients without an override. The same configuration options will apply for users when quota.type=users,

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 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". Quota configuration for users will be handled in the same way as for clients.

Compatibility, Deprecation, and Migration Plan

quota.type is set to  clients as default to be consistent with Kafka 0.9.0.x. Hence the existing quota configurations will apply if new secure quotas are not defined. If quota.type is set to user 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 for this feature at the moment, a simpler single-level user quota was preferred.

 


  • No labels