openstack team mailing list archive

[Raphael Cohn <raphael.cohn@xxxxxxxxxxx>]

Would there be any advantage in moving the quota checks inside the MQ?

eg for nodes, links, RAM usage, disk usage, etc.

Would there also be an advantage in using the SASL 'authzid' and 'authcid',
ie user authenticated as x, but authorized to act as role y?

Raphael Cohn
Managing Director
raphael.cohn@xxxxxxxxxxx
StormMQ Limited

UK Office:
Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN,
United Kingdom
Telephone: +44 845 3712 567

Registered office:
78 Broomfield Road, Chelmsford, Essex, CM1 1SS, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number
07175657
StormMQ.com


On 2 October 2011 03:13, Mike Scherbakov <mihgen@xxxxxxxxx> wrote:

> Joshua,
> user is authorized before the call gets to the scheduler.
> If user authorized, before any calls to the scheduler, there is a check if
> he doesn't exceed quotas.
>
> If user authorized, has right role and doesn't exceed quotas - then message
> is sent to the scheduler.
>
> My point of view is these checks along with SASL for MQ are enough.
> I would also recommend to run all OpenStack services in separated
> management VLAN,
> so Rabbit should not even be accessible from projects' networks.
>
> Regards,
>
> On Sat, Oct 1, 2011 at 6:27 PM, l jv <ljvsss@xxxxxxxxx> wrote:
>
>> If i am not wrong,the rabbitmq have a password
>>
>>
>> 2011/10/2 Joshua Harlow <harlowja@xxxxxxxxxxxxx>
>>
>>>  The question is more along the lines of this:
>>>
>>> So say u have ssl enabled, which is good.
>>>
>>> But should all actions/messages on the message queue also be verified
>>> before they are applied as coming from the correct user?
>>>
>>> Say u have an initial API call that says make me a server for user X.
>>>
>>> Now the scheduler gets that, it should then again verify that X can make
>>> a server (and so on).
>>>
>>> This kind of verification (time sensitive also) should seem like it would
>>> be useful, complimenting SSL for each component that receives a message.
>>>
>>> This would stop malicious (or limit) users hacking the message queue and
>>> spawning requests themselves. Just a thought.
>>>
>>>
>>> On 9/29/11 8:11 PM, "Mike Scherbakov" <mihgen@xxxxxxxxx> wrote:
>>>
>>> Joshua,
>>> your question scares me :)
>>>
>>> Actually you can define user/pass for rabbitmq:
>>> See in rpc/impl_kombu.py, which is used by default:
>>>  308         self.params = dict(hostname=FLAGS.rabbit_host,
>>>  309                           port=FLAGS.rabbit_port,
>>>  310                           userid=FLAGS.rabbit_userid,
>>>  311                           password=FLAGS.rabbit_password,
>>>  312                           virtual_host=FLAGS.rabbit_virtual_host)
>>>
>>> But this seems to be not secured connection, since I don't see here usage
>>> of SSL.
>>> In rpc/impl_carrot.py:
>>>   66             params = dict(hostname=FLAGS.rabbit_host,
>>>   67                           port=FLAGS.rabbit_port,
>>> *  68                           ssl=FLAGS.rabbit_use_ssl,
>>> *  69                           userid=FLAGS.rabbit_userid,
>>>   70                           password=FLAGS.rabbit_password,
>>>   71                           virtual_host=FLAGS.rabbit_virtual_host)
>>> but I never tried this carrot and don't know if it works.
>>>
>>> Can someone else clarify the question? It seems important in terms of
>>> security.
>>>
>>> Thanks,
>>>
>>> On Wed, Sep 21, 2011 at 2:20 PM, Joshua Harlow <harlowja@xxxxxxxxxxxxx>
>>> wrote:
>>>
>>> A quick security question.
>>>
>>> Is there any plan to force authentication/authorization of the rabbitmq
>>> messages?
>>>
>>> Right now it seems like keystone (tbd) will protect the
>>> external<->openstack layers but what about the openstack<->openstack layers.
>>>
>>> If someone got access to the rabbitmq it seems like without this kind of
>>> layer bad things could happen (create me 1000 nodes...).
>>>
>>> Has there been any thought in that area?
>>>
>>> -Josh
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>
>
> --
> Mike Scherbakov
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>