You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Adrian Preston <PR...@uk.ibm.com> on 2015/04/15 15:15:09 UTC
Will it be possible to apply quotas based on a security principal?
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
Re: Will it be possible to apply quotas based on a security principal?
Posted by Adrian Preston <PR...@uk.ibm.com>.
Jay,
Thanks for the explanation - makes sense to me. I'd certainly be happy
to work on a patch that implement this option.
Regards
- Adrian
-----Jay Kreps <ja...@gmail.com> wrote: -----
To: "dev@kafka.apache.org" <de...@kafka.apache.org>
From: Jay Kreps <ja...@gmail.com>
Date: 04/15/2015 07:42PM
Subject: Re: Will it be possible to apply quotas based on a security principal?
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 <PR...@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
>
>
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
Re: Will it be possible to apply quotas based on a security principal?
Posted by Tong Li <li...@us.ibm.com>.
If it is all possible I think we can introduce request pipeline
architecture for producer, broker and consumer (does not have to be done
all at once), that way, security, quota, encryption, serialization,
compression all can be done as plugable components. One can freely stack
them up or tear them apart at the configuration level. Each component can
have its own design and implementation. Any deployed can choose what
interest him or her. Components have no dependency among each other. New
features can be easily added/tried/removed/abandoned. When I looked at our
code, instrument this so called pipeline can be very easy. Wonder if any of
you guys interested.
Thanks.
Sent from my iPhone
> On Apr 15, 2015, at 4:14 PM, Jay Kreps <ja...@gmail.com> wrote:
>
> 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 <PR...@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
> >
> >
Re: Will it be possible to apply quotas based on a security principal?
Posted by Jay Kreps <ja...@gmail.com>.
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 <PR...@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
>
>