Open Stack

Hi all,

At this moment we have a couple of services that need to consume
connections from a message queue on the client side.

This raised change requests to fix the issue with different approaches.
Those change requests have several implications on Kolla's overall
architecture and security, being said, will need a discussion for message
queue consumers from client side in order to apply the best solution,
avoiding as far we can all risk in the infrastructure.


As far as I know, murano-agent and trove-agent need to connect to RabbitMQ
in order to consume configurations and status tracking from the deployed
services. The agent is installed in the instances. [0] [1]


Using Murano as example, when a new application is deployed, murano-agent
configuration is injected in the instances through cloud-init with RabbitMQ
connection information (user, URL and password). Once the instance start,
murano-agent communicates with murano-engine through RabbitMQ in order to
get application configurations.


As we have in Kolla at the moment, Murano won't work unless using older
Murano applications on which the application has been previously installed
and configured in the base image.


>From this design I have three different options to fix the issue.



   -

   Allow services to use actual RabbitMQ cluster in a different vhost: [3]
   [4]
   -

      Pros:
      -

         Easy to fix now, there are PS under review at the moment for
         Murano.
         -

         Provides some kind of isolation per service as well as more secure
         with different user/password.
         -

      Cons:
      -

         Expose OpenStack infrastructure RabbitMQ to to end-users.
         -

         Risk of DDoS attacks to the whole OpenStack infrastructure,
         end-user instances will have access to a shared RabbitMQ
between OpenStack
         and them.
         -

   New RabbitMQ instances (per service or shared with other services): [5]
   -

      Pros:
      -

         More secure option, avoid DDoS against the infrastructure and
         network access to OpenStack RabbitMQ.
         -

      Cons:
      -

         Overload underlay infrastructure with more RabbitMQ instances.
         -

         Inability to use standard ports because more than one RabbitMQ can
         share the same node.
         -

         Complex option to deploy, debug and maintain.
         -

   Expose current RabbitMQ to end-user services.
   -

      Pros:
      -

         Simple, easy and less resource consuming.
         -

      Cons:
      -

         Hell no, this is not an option.
         -

         Share OpenStack's RabbitMQ cluster admin password and expose
         network access to end-users.



There is a thread which explains the issue and solutions recommended by
other teams. [6]


Please, share your opinion on this matter.


[0]
https://github.com/openstack/murano/blob/master/doc/source/administrator-guide/murano_agent.rst

[1] https://wiki.openstack.org/wiki/Trove/guest_agent_communication

[3] https://review.openstack.org/#/c/410825/

[4] https://review.openstack.org/#/c/411760/

[5] https://review.openstack.org/#/c/374525/

[6] http://www.gossamer-threads.com/lists/openstack/operators/57816



Regards, Eduardo Gonzalez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161216/192e3a8f/attachment.html>