Open Stack

On Thu, 2013-06-13 at 16:50 -0500, Kevin L. Mitchell wrote:
> At present, all the information that allows cells to communicate to each
> other—including the Rabbit username and password—is stored in the
> database, in clear text; while not really a security issue (if someone
> can read your database, you're already on quicksand, security wise),
> this is somewhat undesirable.  I would like to try to address this
> issue, but I can really only come up with two basic approaches, both of
> which will cause some migration issues, so I'm hoping to kick off a
> discussion as to which will be the more acceptable solution.
> 
> The first potential solution is to simply encrypt the password in the
> database.  (Actually, I intend to first merge all of the RPC information
> into a single database field, then encrypt that; that will make it
> easier to allow for alternate communication mechanisms in the future.)

Bear in mind that we're adding the notion of a transport URL to
oslo.messaging, partly for cells:

  https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_URLs

> The problem with this approach is the key management problem: we either
> have to encrypt the data during the migration, or provide a mechanism
> whereby the data may be lazily encrypted at runtime; and we must also
> allow for rekeying later on.
> 
> The second potential solution is to drop the cells table from the
> database and place all the data regarding cells (including the
> connection information) into a configuration file.  (Not the master
> configuration file; my vision here is to add a single option that says
> to load cells data from an auxiliary JSON file, a la policies.)  The
> problem with this approach, of course, is that the data has to be
> migrated out of the database and into that JSON file in some fashion;
> this can't really be adequately handled via database migrations.  We
> also necessarily lose the ability to add and remove cells via the API.

Putting it in a config file and losing the cells management API seems
fine to me. Not entirely sure why, but it doesn't feel unlike a lot of
other stuff we have in our config files.

Is there any reason not to just put it in nova.conf as transport URLs?

(By nova.conf, I mean cfg.CONF for nova which means you could happily do
e.g. --config-file nova-cells.conf too)

> I have thought of one way to at least partially mitigate the downsides
> of the second solution: allow the cell data to come from the database OR
> the file.  We could then create a simple tool that could allow you to
> extract the data from the database and store it in a file later on,
> after the migration.  In this scenario, the "cells" table remains for
> the Havana release, then a later migration would remove it for Icehouse.
> We would still need to ensure that the pending deprecation is carefully
> documented, along with the migration strategy, so that existing users
> aren't caught by surprise…

Makes sense to me.

Cheers,
Mark.