I think this should be a fairly minor follow-up item to have the quotas key off of user rather than client id. The advantage of starting with client.id is that it decouples the security work from the quota work in the short term and provides a mechanism for those using Kafka without authentication to still enforce quotas.
On Wed, Apr 15, 2015 at 6:15 AM, Adrian Preston <prest...@uk.ibm.com> wrote: > Hi, > > I've been investigating using Kafka for a multi-user system that applies > quotas at a per-user level. Reading through KIP-13 and KAFKA-1682, I > wondered: are there any plans to link together the security principal and > client identifier in some way? Currently it appears these are separate > concepts - so I can't see any way to apply a quota based on the > authenticated identity of a user. > > > Regards > - Adrian > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >
