Open Stack

There have been various discussions about this before.

There are actually two issues if you don't like a security breach on a
single node to compromise other systems:

* messages are not verifed
* database access is global

As you've said anyone with access to the queue can send any message
and masquerade as if it is from another node.  We've talked about
adding signatures to messages (each node would have a private key that
it uses to sign messages).

But even if we accomplish that, we still have the problem that each
node has read/write access to the datastore.  Vish & Termie had
attempted to start fixing this by patching nova to send all the
relevant data over the queue so that workers don't need to have access
to the database.  Unfortunately this didn't land in Diablo.

We were hoping to isolate the privilege escalation to the queue and
then improve the queue with signatures or other techniques.

I'm interested in hearing ideas about how isolation should be implemented.

Best,
Jesse


On Sat, Oct 1, 2011 at 6:18 PM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:
> 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 at gmail.com> 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 at yahoo-inc.com>
> 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>