Open Stack

On 03/19/2016 11:33 PM, Joshua Harlow wrote:
> Howday all,
>
> Just to start some conversation for the next cycle,
>
> I wanted to start thinking about what folks may like to see in oslo 
> (or yes, even what u dislike in any of the oslo libraries).
>
> For those who don't know, oslo[1] is a lot of libraries (27+) so one 
> of my complaints (and one I will try to help make better) is that most 
> people probably don't know what the different 'offerings' of these 
> libraries are or how to use them (docs, tutorials, docs, and more docs).
>
> I'll pick another pet-peeve of mine as a second one to get people 
> thinking.
>
> 2) The lack of oslo.messaging having a good security scheme (even 
> something basic as a hmac or signature that can be verified, this 
> scares the heck out of me what is possible over RPC) turned on by 
> default so I'd like to start figuring out how to get *something* 
> (basic == HMAC signature, or maybe advanced == barbican or ???)

Red Herring.  We don't need HMAC. We need to make better use of the 
tools in Rabbit.

1.  Split the vhosts between notifications and control plan.  The code 
is in place to do this already, but we need to update the configuration 
tools to make use of that.

2.  Drop the default login and password.  All services, and all compute 
nodes should get their own Rabbit user and an autogenerated password.  
Even better would be to use Client Certificate validaltion, but that 
requires a CA.

3. We desperately need a CA story.

4.  ACLs set up aroun the reply queus.  If I send a message to 
openstack-compute-15, only that compute should be able to rite to the 
resposne queue.  This could be done with a naming scheme and regex in 
the ACL.


HMAC is crypto, and is going to put a load on the CPUs.  While this is 
acceptable in the generation of messages from the Compute nodes 
(distributed load) validation and generation of HMAC on the controller 
nodes is just an additional requirement.


What I would like to see, before we engineer anything else, is a map of 
the components that talk via the Broker, the topics and queues they 
should have access to, and the paths of messages between them.

I started with a blog post here:

http://adam.younglogic.com/2016/03/what-can-talk-to-what-on-the-openstack-message-broker/

and did a brief spike here:

http://adam.younglogic.com/2016/03/tie-your-rabbit-down/

We made the mistake of pursuing HMAC back several releases ago.  It lead 
to Kite.  We don't need that yet.




>
> What other thoughts do people have?
>
> Good, bad, crazy (just keep it PG-13) thoughts are ok ;)
>
> -Josh
>
> [1] https://wiki.openstack.org/wiki/Oslo
>
>
> __________________________________________________________________________ 
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev