Secure multitenancy in engine->agent communication

Registered by Steve McLellan on 2014-05-20

Agent configuration is injected by the engine at deploy time. At the moment a shared username, password and vhost are used for all environments and instances.

Input queue names to resources are determined as a function of their object and environment id, so the chances of accidental collision is low.
Output queue names belong to an environment and currently are `-execution-results-<environment name>` (e.g. `-execution-results-quick-env1`). This makes collisions possible between environments owned by different users (or even the same user in some circumstances). (Filed bug

In addition to the chance of accidental collision, there's an opportunity for intentional mischief since nothing stops an agent on one host sending messages to another, presuming it is able to determine the id (as a proof of concept, an agent template could be constructed that queried rabbitmq for queues using the python API, for example). Queues need to be safe at least within tenants.

The output queue name problem can be made less problematic by using the environment id in the queue name ( but we need a solution for authenticating agent queues.

Some suggestions that came up before:
* distinct username/password (per tenant)
* auth keys (per tenant)
* separate vhosts (per tenant)

The issue with all of these is that it means the engine needs a lot of access to rabbitmq. Marconi potentially would solve all these problems, but likely will not be guaranteed available in the juno timeframe.

Blueprint information

Not started
Ruslan Kamaldinov
Steve McLellan
Dmytro Dovbii
Series goal:
Not started
Milestone target:
milestone icon next

Related branches



Exact solution design need to be discussed

This can be used:
Instead of configuring RabbitMQ (creating users, permissions etc) engine can have a little embedded web server that accepts requests from RabbitMQ and have API to register temporary login name and set of permissions. This way there is no need to remove users that are no longer used and login/password/permission is only valid when corresponding environment get processed by engine and it is always consistent

Or this:

@efedorova: Agreed, if we are presenting Murano as secure app deployment, it should be 100% secure.


Work Items

This blueprint contains Public information 
Everyone can see this information.