openstack team mailing list archive

["Day, Phil" <philip.day@xxxxxx>]

Yep - good point Chris & Kevin.  I hadn't thought of it that way.

-----Original Message-----
From: openstack-bounces+philip.day=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+philip.day=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Chris Behrens
Sent: 30 March 2012 00:30
To: Kevin L. Mitchell
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Distributed rate-limiting

My issue with using the URL is someone could easily DoS any tenant.  Maybe you said that below.  I only have a brief moment to scan email ATM. :)

On Mar 29, 2012, at 5:26 PM, "Kevin L. Mitchell" <kevin.mitchell@xxxxxxxxxxxxx> wrote:

> On Thu, 2012-03-29 at 22:58 +0100, Day, Phil wrote:
>> - As you get the tenant id from the context I assume this module has
>> to come after the authentication in the pipeline.   
> 
> Yes, I have made that assumption.  It seems reasonable, given that the 
> existing rate-limit middleware is right after authentication as well.
> 
>> Have you thought about using the tenant_id in the URL instead ?   (I'm
>> thinking of the case where you want rate limit requests into the 
>> authentication system as well as Nova itself).
> 
> No, I haven't.  I don't trust the user, which is where the tenant_id 
> in the URL comes from.  I do trust the auth system, which is why I 
> want to use the tenant ID from the context.  (And yes, you could argue 
> that authz would prevent their access to other tenants anyway, but why 
> make nova have to check authz if rate limiting would stop them in the 
> first
> place?)
> 
> As for rate limiting requests into the authentication system, I'd 
> suggest using a Limit subclass which uses the remote IP address in 
> place of a tenant ID, at least for the user endpoint.  I don't think 
> we want any rate limiting at all on the service side of Keystone; our 
> current architecture means that Keystone is going to be hit a *lot*: 
> at least once for each request that hits Nova, and more in certain 
> cases (i.e., instance boot, where we'll have to hit quantum and glance as well).
> 
>> - Does this work for EC2 as well as OSAPI ?
> 
> Actually, it didn't occur to me to test, given that I don't really use 
> the EC2 API.  I don't think there's anything in the basic architecture 
> which would be incompatible with EC2; the only possible sticking point 
> that occurs to me is the URL construction in
> nova_limits:NovaClassLimit.route(): if the URL specified is prefixed 
> with '/v1.1/' or '/v2/', the version identifier is dropped (otherwise 
> the route wouldn't match).  That would be easy to work around; simply 
> extend NovaClassLimit and override route() to do the appropriate 
> transformation for EC2.  Any EC2 experts want to weigh in?
> --
> Kevin L. Mitchell <kevin.mitchell@xxxxxxxxxxxxx>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp